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

[520Bit]

Bitcoin 0.9.0 final version is available to download now: https://bitcointalk.org/index.php?topic=522014

Is there any risk to Counterpart client if I upgrade my Bitcoin-Qt to 0.9.0?

[halfcab123]

Bitcoin 0.9.0 final version is available to download now: https://bitcointalk.org/index.php?topic=522014

Is there any risk to Counterpart client if I upgrade my Bitcoin-Qt to 0.9.0?

Great question bump!

[PhantomPhreak]

Bitcoin 0.9.0 final version is available to download now: https://bitcointalk.org/index.php?topic=522014

Is there any risk to Counterpart client if I upgrade my Bitcoin-Qt to 0.9.0?

Great question bump!

Looking at the changelog, it shouldn't break horribly, but there is at least one tweak to be made w.r.t. the walletpassphrase RPC call. Give us a little while to do some testing.

[led_lcd]

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.

Code:

Asset Short name    Long name                    
BITT                BITT                         
KEOdAi3q            BITT.spanish.dubloon         
OIu3waqn            BITT.spanish.dubloon#1       
RPGGAME             RPGGAME
LPJhiowG            RPGGAME.ruby.cracked
jrOyehHG            RPGGAME.ruby.perfect
BANK                BANK
OIJFE7ig            BANK.I can type whatever I like

Client visualization

Code:

BITT
 +-spanish
         +-dubloon
         +-dubloon#1
RPGGAME
 +-ruby
      +-cracked
      +-perfect
BANK
 +-I can type whatever I like

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

Code:

BITT
 +-spanish.dubloon
 +-spanish.dubloon#1

RPGGAME
 +-ruby.cracked
 +-ruby.perfect

BANK
 +-I can type whatever I like

[leonArdo@margin]

Hej.

I am one of the three guys who developed a trading application/framework called leonardo.  
At first we just wanted to create a better trading interface for centralized exchanges but with the built-in market abstraction layer it shouldn't be that hard to get it to talk to counterpartyd.
What do you think? Do you like the idea? Do you see problems?

More info on leonardo at:
https://bitcointalk.org/index.php?topic=506317.0

If you have scam concerns, please read our announcement before yelling at us

[halfcab123]

Hej.

I am one of the three guys who developed a trading application/framework called leonardo.  
At first we just wanted to create a better trading interface for centralized exchanges but with the built-in market abstraction layer it shouldn't be that hard to get it to talk to counterpartyd.
What do you think? Do you like the idea? Do you see problems?

More info on leonardo at:
https://bitcointalk.org/index.php?topic=506317.0

If you have scam concerns, please read our announcement before yelling at us

What would it add to what the protocol already does

[leonArdo@margin]

What would it add to what the protocol already does

nothing
It does not add something to the core protocol. It is a front-end to the functionality of the protocol itself.
It would basically provide the functionality that website of centralized exchange (cryptsy, poloniex) provides.

[PhantomPhreak]

Hej.

I am one of the three guys who developed a trading application/framework called leonardo.  
At first we just wanted to create a better trading interface for centralized exchanges but with the built-in market abstraction layer it shouldn't be that hard to get it to talk to counterpartyd.
What do you think? Do you like the idea? Do you see problems?

More info on leonardo at:
https://bitcointalk.org/index.php?topic=506317.0

If you have scam concerns, please read our announcement before yelling at us

That's a great idea. I love it. It'd be great to have such an interface to Counterparty, which indeed right now has a good deal of functionality under the hood, but is somewhat lacking in powerful and intuitive interfaces. The only potential problem I see is in trading with BTC on Counterparty, which requires a follow-up transaction (and API call) to finalize the purchase of another asset. Of course, that won't stop it from working with user-created assets and XCP.

Is the code all closed-source? What are you looking for, from us, to add Counterparty support to leonardo?

[cityglut]

Hej.

I am one of the three guys who developed a trading application/framework called leonardo.  
At first we just wanted to create a better trading interface for centralized exchanges but with the built-in market abstraction layer it shouldn't be that hard to get it to talk to counterpartyd.
What do you think? Do you like the idea? Do you see problems?

More info on leonardo at:
https://bitcointalk.org/index.php?topic=506317.0

If you have scam concerns, please read our announcement before yelling at us

That's a great idea. I love it. It'd be great to have such an interface to Counterparty, which indeed right now has a good deal of functionality under the hood, but is somewhat lacking in powerful and intuitive interfaces. The only potential problem I see is in trading with BTC on Counterparty, which requires a follow-up transaction (and API call) to finalize the purchase of another asset. Of course, that won't stop it from working with user-created assets and XCP.

Is the code all closed-source? What are you looking for, from us, to add Counterparty support to leonardo?

I agree, it's a really great idea.

Couldn't there be client-side "automated BTCpay", though?

[leonArdo@margin]

That's a great idea. I love it. It'd be great to have such an interface to Counterparty, which indeed right now has a good deal of functionality under the hood, but is somewhat lacking in powerful and intuitive interfaces. The only potential problem I see is in trading with BTC on Counterparty, which requires a follow-up transaction (and API call) to finalize the purchase of another asset. Of course, that won't stop it from working with user-created assets and XCP.

Is the code all closed-source? What are you looking for, from us, to add Counterparty support to leonardo?

We also think counterparty and leonardo could be a great fit.
Even so leonardo is not open source (yet) and will stay that way for a while.
Until now our abstraction layer was designed for centralized exchanges in mind but I don't see a big problem in adding additional xcp related functionality (even follow-up transactions).
All we have to do is talk to counterpartyd/bitcoind locally + maybe some state/event handling, right?
I have to take a closer look at it though. Haven't had enough time to play with counterpartyd other than setting it up

[leonArdo@margin]

I agree, it's a really great idea.

Couldn't there be client-side "automated BTCpay", though?

If I understand that correctly, than that's exactly what leonardo was built for:
Handle stuff that you don't wanna handle manually while providing the functionality via an easy to use interface

[PhantomPhreak]

That's a great idea. I love it. It'd be great to have such an interface to Counterparty, which indeed right now has a good deal of functionality under the hood, but is somewhat lacking in powerful and intuitive interfaces. The only potential problem I see is in trading with BTC on Counterparty, which requires a follow-up transaction (and API call) to finalize the purchase of another asset. Of course, that won't stop it from working with user-created assets and XCP.

Is the code all closed-source? What are you looking for, from us, to add Counterparty support to leonardo?

We also think counterparty and leonardo could be a great fit.
Even so leonardo is not open source (yet) and will stay that way for a while.
Until now our abstraction layer was designed for centralized exchanges in mind but I don't see a big problem in adding additional xcp related functionality (even follow-up transactions).
All we have to do is talk to counterpartyd/bitcoind locally + maybe some state/event handling, right?
I have to take a closer look at it though. Haven't had enough time to play with counterpartyd other than setting it up

Great. You actually don't have to talk to Bitcoind at all... only counterpartyd. Some state/event handling, yes. Keep us posted. If you have any questions, don't hesitate to PM or e-mail me.

[kdrop22]

Hej.

I am one of the three guys who developed a trading application/framework called leonardo.  
At first we just wanted to create a better trading interface for centralized exchanges but with the built-in market abstraction layer it shouldn't be that hard to get it to talk to counterpartyd.
What do you think? Do you like the idea? Do you see problems?

More info on leonardo at:
https://bitcointalk.org/index.php?topic=506317.0

If you have scam concerns, please read our announcement before yelling at us

Looking forward to the integration between Leonardo and counterparty distributed exchange.

[ginko-B]

For example, there are thousands of types of silvercoins with different make, quality, size, and ownership histories. We use generic catalog names to make these assets easy to identify in our catalog and easy for our customers to discretely digitize and trade. We respect this diversity and don't aim to constrain it as we didn't create it ourselves.

It makes sense now.

BTT thanks for your post, I think I understand a bit better what you are proposing to do. Can I just clarify your business model a little bit out of curiosity? It sounds like you will essentially be a middle man listing assets on behalf of others, for which you will charge a fee. In this case the requirement to issue several assets is understandable and I can appreciate your desire to keep costs down.

However, I still think that asset squatting is an issue for usability, although I think that this can probably be addressed on the client side by filtering assets somehow. Don't get me wrong, I like that you are helping the system develop, my only issue is that, under a low issuance fee scenario, I can see the whole thing degenerating to a free for all where we have a million assets that have been squatted on or don't really represent or mean anything. If I was a new user I would take one look at that, think that there was nothing in CP I was interested in, and go elsewhere.

I don't know if this is practical from a protocol perspective, but one idea that I think was mentioned before would be to charge a reasonably large fee for a top level asset name (E.g. BTT-Coin or BTT) and then have no or minimal fees for sub assets (BTT-Coin.gold; BTT-Coin.silver; BTT-Coin.1gold.5silver; Etc).

I also wondered if we should make a distinction between hard assets and financial assets at the protocol level or at least on the client side to allow people to find the assets they are interested in. I have always envisaged CP as a crowd funding vehicle or a way to raise money for new businesses. Obviously that is not the only application but it is the one that for me personally is most compelling to the value of the whole protocol and infrastructure.

Anyway just some thugs I've been thinking about. I'll be watching the development of BTT with interest!

EDIT: sorry for this redundant post, I wrote it yesterday but was only able to access the site now to post, and in the meantime caught up on all the other posts addressing this. Fully supportive of these suggestions!

I like the idea of a hierarchical fee structure.  Maybe GLDBTTXXXXX

Where,
GLD = Gold
BTT = Bitcoin Tangible Trust (i.e. Issuer of assets)
XXXXX = Asset ID  (i.e. individual assets in the catalog, fully redeemable thru the BTT redemption procedure, eg. silver coins)

Maybe top level names such as GLD are not even available for purchase -- they would common property of all users of the protocol -- and then BTT could pay, say, 5 XCP for the GLDBTT name, and then for each unique asset created under that name, ie. GLDBTTXXXX1, GLDBTTXXXX5, then BTT could pay, say, 0.01 XCP, or something de minimus, so as not to create a competitive disadvantage for the business model.

EDIT:  I posted this prior to reading the thread from GLaDOS referencing the idea posted earlier on the official forums.  

EDIT 2: I actually like the "dots" as proposed by GLaDOS, eg. GLD.BTT.XXXX1, makes it easier on my eyes!  =)

EDIT3: A question for everyone, should it be "GLD.BTT.XXXX1" or "BTT.GLD.XXXX1" - does it matter?  

[ginko-B]

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.

Upon first glance this seems pretty damn genius. It's genius because its so simple its almost obviously the way it should be. I hope the developers strongly consider implementing this or something quite like this, as soon as robot/human-hybridally possible.

Edit: That being said this may be something left to other developers to build on top of Counterparty, but I think its fundamental enough to be included in the protocol layer itself.

Think:

Code:

Issuer.Issuance.Sub-Issuance

And so once an issuer name is chosen, that issuer can create other issuer names of course but they will be the only ones who are permitted to create issuances and sub-issuances relative hierarchically to their issuer name.

And then perhaps blockscan can implement a nice new GUI feature which will allow for collapsing and expanding assets based on this hierarchy of issuance. This will make searching for assets and trusting assets that are issued much much easier and much cleaner of an experience. Good idea GLaDos.

Edit 2: In addition, fees can be adjusted, say... maybe 5 - 10 XCP more or less to register an issuer name, but the issuance might be half that and then the sub-issuances might be even half of half etc., This makes sense to me, but I'm waiting for someone to tell me I'm an idiot or that its not feasible as is common round these parts. -___-

+1
Agreed, this is a good suggestion.

+1

[ginko-B]

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.

The BitcoinTangibleTrust team supported this approach on the official forums, as well. Global_trade_repo's suggestion was genius. We like it for more extensive naming degrees of freedom.

+1, BTT agreeing here too

[frozen123]

Article by @CoinTelegraph - Counterparty to Set New Standard of Fairness in the Cryptographic World: http://cointelegraph.com/post/counterparty_to_set_new_standard_of_fairness_in_the_cryptographic_world      info   from Counterparty twitter!

[led_lcd]

I've added to my proposal a textual visualization on what the hierarchy would look like.

https://bitcointalk.org/index.php?topic=395761.msg5783153#msg5783153

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

Code:

Asset Short name    Long name                    
BITT                BITT                         
KEOdAi3q            BITT.spanish.dubloon         
OIu3waqn            BITT.spanish.dubloon#1       
RPGGAME             RPGGAME
LPJhiowG            RPGGAME.ruby.cracked
jrOyehHG            RPGGAME.ruby.perfect
BANK                BANK
OIJFE7ig            BANK.I can type whatever I like

Client visualization

Code:

BITT
 +-spanish
         +-dubloon
         +-dubloon#1
RPGGAME
 +-ruby
      +-cracked
      +-perfect
BANK
 +-I can type whatever I like

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

Code:

BITT
 +-spanish.dubloon
 +-spanish.dubloon#1

RPGGAME
 +-ruby.cracked
 +-ruby.perfect

BANK
 +-I can type whatever I like

[PhantomPhreak]

I've added to my proposal a textual visualization on what the hierarchy would look like.

https://bitcointalk.org/index.php?topic=395761.msg5783153#msg5783153

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

Code:

Asset Short name    Long name                    
BITT                BITT                         
KEOdAi3q            BITT.spanish.dubloon         
OIu3waqn            BITT.spanish.dubloon#1       
RPGGAME             RPGGAME
LPJhiowG            RPGGAME.ruby.cracked
jrOyehHG            RPGGAME.ruby.perfect
BANK                BANK
OIJFE7ig            BANK.I can type whatever I like

Client visualization

Code:

BITT
 +-spanish
         +-dubloon
         +-dubloon#1
RPGGAME
 +-ruby
      +-cracked
      +-perfect
BANK
 +-I can type whatever I like

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

Code:

BITT
 +-spanish.dubloon
 +-spanish.dubloon#1

RPGGAME
 +-ruby.cracked
 +-ruby.perfect

BANK
 +-I can type whatever I like

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.

[led_lcd]

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