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

Good point. Let me then do what I'm good at: Backroom political dealing with greasy fingers.

I will reach out to Jeff via some of the Bitpay bitcore devs to explore if we can share an introduction to the Counterparty devs to explore the OP_RETURN options. The Bitpay devs are already impressed that Counterparty is using Bitpay's Insight for Counterwallet.

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.

It would be very hard to seriously say there isn't a technical reason for OP_Return to be 80 that they aren't aware of.

+1
We need to engage them, in a dialog.

I can't argue how you feel about the core devs. However, no one stood up to the technical merits of why 80 bytes was needed. Jeff and Gavin have simply made claims about 40 byte change being good enough and SPAM being a problem. Unfortunately, I did not have the technical breadth to ask how they came to those conclusions, but disengaging in the technical discourse is not letting others understand the potential.

The open letter was a first step to engage, but it's not good enough. We need to say something on the list.

We are on that mailing list. The Bitcoin core development team is just a cabal, and they need to see popular demand for features before they support them. Otherwise, they're too inclined to be conservative for the sake of being conservative, e.g. in this case, where there is no actual justification for their decisions. It just makes the situation worse.

This post is great, but this is now how the bitcoin core team works to make a change. Here's my 3 steps for engaging the bitcoin core dev team on the change which may not guarantee anything will happen, but is better than an open letter which they will most likely never read.

Step 1: Counterparty Devs need to get on the bitcoin core dev mailing list and understand the decision making process and how the core devs see OP_RETURN. Hint: They mostly don't like it.

Here's the discussion when they decided to go from 80 bytes to 40.
http://www.mail-archive.com/[email protected]/msg04013.html

and here's Gavin's opinion about 40 bytes
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04018.html

Step 2: The Counterparty Core devs here need to get on that mailing list and share (not argue) their technical points for a 75 byte or 80 byte limit. The biggest concern is SPAM on the blockchain. How does Counterparty prevent SPAM when Mastercoin or others may do so? It may require Counterparty providing some ways to fix OP_RETURN to help address these issues. This is contributing to the bitcoin core. Mastercoin is absent from this list most likely because they have given up on representation so there may be room for new voices.

Step 3: Assume that this change will not happen immediately (if at all), but will need to be pressed weekly. Counterparty devs need to get on that mailing list so they can see to whom they can send direct notes to appeal the change, including engaging Jeff Garzik and Gavin Andresen, explaining why this is technically important and why it will not lead to abuse.

You can't argue from afar. You must engage and you must acquire the attention of key stakeholders in this discussion. You must join the bitcoindevs mailing list and represent the Counterparty position.

However, none of this is a guarantee that any action will be taken.

Plea to Core Bitcoin Developers regarding OP_RETURN: https://www.counterparty.co/plea-bitcoin-core-development-team/

Don't change that Bitcoin2.0 dial!

Stay Tuned on the Counterparty Cable Channel!

http://img.pandawhale.com/47778-wrestler-dis-gon-b-gud-gif-Img-O4EB.gif

We'll be issuing a statement on these new proposals, other radical protocol changes that were previously made, and an explanation for recent stakeholder flight in a few hours.

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

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.

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

https://bitcointalksearch.org/topic/m.5783153

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



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

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!

+1, BTT agreeing here too

+1

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?  

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

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.

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