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

[MoneypakTrader.com]

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.

[Bountyful]

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.

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

[Matt Y]

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

[BitcoinTangibleTrust]

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

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/bitcoin-development@lists.sourceforge.net/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.

[PhantomPhreak]

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

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/bitcoin-development@lists.sourceforge.net/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. I would recommend also sending a direct note to Jeff Garzik and Gavin explaining why this is 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.

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.

[BitcoinTangibleTrust]

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

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/bitcoin-development@lists.sourceforge.net/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. I would recommend also sending a direct note to Jeff Garzik and Gavin explaining why this is 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.

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.

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.

[kdrop22]

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.

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

[porqupine]

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.

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.

[GLaDOS]

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

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.

[BitcoinTangibleTrust]

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.

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.

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.

[nakaone]

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

what is the outcome for the protocol?

explain to me like I am five

[kdrop22]

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

what is the outcome for the protocol?

explain to me like I am five

The protocol will continue to work. However, the solution we are using currently is not an elegant solution.

[Matt Y]

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

what is the outcome for the protocol?

explain to me like I am five

Everything will stay the same for now and there is no cause for concern. If OP_RETURN had more room to store information, that would be a positive change for Counterparty, other similar projects, and would improve the long term health of the Bitcoin blockchain.

[IamNotSure]

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

what is the outcome for the protocol?

explain to me like I am five

I guess it will continue to rely on multisig outputs. Dunno if some small operations can be embedded in OP_RETURN though.

[dexX7]

80 bytes would be better than 40 bytes, but is this amount sufficient to support all XCP transaction types?

[jl777]

80 bytes would be better than 40 bytes, but is this amount sufficient to support all XCP transaction types?

Could the info needed be compressed to fit into 40 bytes?
What sort of entropy does the typical XCP OP_RETURN data have?

Depending on the data, it might be possible to create a small customized compress/decompress function

If someone can post an example it would help me analyze this a bit more

Edit: due to the importance of this I think it would even make sense to create a custom "dictionary" of common bit patterns (hopefully there are some) in the desired OP_RETURN data. This would have to be put into the counterpartyd, but doing stuff like this might be what is needed to get 2:1 compression, then again maybe standard compression will just work, but I think some sort of custom code would have a good chance. It all depends on the type of data.

James

[led_lcd]

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 hash and encoded into base 26 anyway.

Yes, that's basically the gist of it. Take a long asset name and fold it into a short asset name.

The benefit of the distinction between a top level and lower level asset issuance is to give a means to tier the costing of issuing assets in a simple fashion.

I'd be happy to stay with the status quo plus a defacto standard on how to craft the asset description to include a namespace as long as:

a) If we think that the current pricing model is only a short term solution until a floating fee solution is found (similar to transmission fees in Bitcoin).

b) The defacto standard is something centralized such that there is agreement in the community.

[PhantomPhreak]

80 bytes would be better than 40 bytes, but is this amount sufficient to support all XCP transaction types?

Could the info needed be compressed to fit into 40 bytes?
What sort of entropy does the typical XCP OP_RETURN data have?

Depending on the data, it might be possible to create a small customized compress/decompress function

If someone can post an example it would help me analyze this a bit more

Edit: due to the importance of this I think it would even make sense to create a custom "dictionary" of common bit patterns (hopefully there are some) in the desired OP_RETURN data. This would have to be put into the counterpartyd, but doing stuff like this might be what is needed to get 2:1 compression, then again maybe standard compression will just work, but I think some sort of custom code would have a good chance. It all depends on the type of data.

James

It would take some serious shoe-horning to fit all of the data we need into 40 bytes reliably, and in three months they could lower it to 35 bytes (again, for no reason) and then we'd be screwed.

On the plus side, we can fit a lot more than 80 bytes into 256 one-of-three multi-sig outputs, and now we have no incentive to use less than that except lower fees.

[PhantomPhreak]

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 hash and encoded into base 26 anyway.

Yes, that's basically the gist of it. Take a long asset name and fold it into a short asset name.

The benefit of the distinction between a top level and lower level asset issuance is to give a means to tier the costing of issuing assets in a simple fashion.

I'd be happy to stay with the status quo plus a defacto standard on how to craft the asset description to include a namespace as long as:

a) If we think that the current pricing model is only a short term solution until a floating fee solution is found (similar to transmission fees in Bitcoin).

b) The defacto standard is something centralized such that there is agreement in the community.

I think that's right.

[GLaDOS]

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

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.