Colored coin whitepaper

[Vitalik Buterin]

This is the colored coin whitepaper I've been working on with Yoni, Alex and Amos for the past few weeks:

https://docs.google.com/document/d/1z7CsBRBgEj3NJeEEFqctFRksfJ1ZKJAiuc7UmtsKNEc/edit

It's pretty close to finished in terms of what I want to do to it, but I welcome anyone's comments.

[Jeremy Spilman]

Thanks Vitalik, Yoni, Alex, and Amos! I think great documentation is the
best way to promote more developer participation, I'm really happy to see
this.

I'm going to throw some ideas out there, please feel free to take what you
like and leave the rest. I hope this is useful.

1) Colored Coins Transfer Transaction Evaluation Algorithm

I'll just call it the "ColorTransfer" function. I think we want to define
this function as tightly as possible, because it helps keep things simple
and increase understanding of the system. At the core;

Color[] ColorTransfer(ColoredInput[] inputs, int[] outputs)

ColoredInput = {
value: [integer],
color: [color]
}

Note, inputs are simply value/color, because colorvalue is a derived
property. You can put 'sequence' in the input as well for tag-based
coloring. The simplest return value is an array of colors which
correspond to the given array of outputs. There is no need to return
'colorvalue' as well, as its redundant. I would also remove 'prev_out'
from the inputs, and 'address' from the outputs, because I can't see how
those are relevant to the ColorTransfer function.

I would hold off on introducing the concept of 'colorvalue' until after
you have discussed the issues with OBC.

After you have discussed OBC and the inherent downsides, then I think what
the reader needs to understand is;

(a) what is 'colorvalue' why is it different from 'value'
(b) how is 'colorvalue' calculated

I think you should consider defining padding as a property of the color,
and explicitly stating that it could be different between colors.

2) Well, most important thing is the implementations. I tried testing the
OBC implementation directly from the whitepaper, but unfortunately ran
into an error...

Tests:
ColorTransfer( [ { color:'a', value:100 } ], [ 100 ] )
--> [ 'a' ]

ColorTransfer( [ { color:'a', value:200 } ], [ 100, 100 ] )
--> TypeError: Cannot read property 'color' of undefined

The error is because the algorithm in the whitepaper does not fully drain
an input which covers two outputs before incrementing 'i', and so when you
get to the next output, you are pointing too far ahead. Please see
attached .js file for an OBC implementation that works.

3) I was surprised at the increased complexity of POBC, because I think
you can actually implement it much the same as OBC.

The algorithm in the whitepaper also has some side-effects I'm not sure
are necessary, for example, if there are any inputs below the padding
threshold at the start of the list, it will mark all outputs as uncolored.

I've implemented the algorithm in the whitepaper, as well as my own POBC
which more closely aligns with OBC in the attached .js file and written
some (very much not comprehensive) tests, and attached the test output as
well.

It's very likely there are bugs in this code, but it's a nice environment
to play with the ColorTransfer algorithms.

4) In the example POBC diagram, why is the 3rd output uncolored?

First, I assume the first two outputs quantity should be 3 and 1 not 1 and
1, to be consistent with the drawing...

The 3rd output is fully covered by the 4 GRC input. Seems like a single
input color covering a full output meets the standard for getting colored.

This seems like another inconsistency between POBC and OBC, if there's a
reason to throw away "3 GRC" in this case, please explain?

I've implemented the failing version of this test case in the attached .js
and you can see it in the last result. My alternate implementation of POBC
does color the 3rd output in this case...

4) I've read the 'Coloring Independence Theorum' repeatedly and I'm just
not sure what it's trying to say. Is it claiming that given a subset of
all color definitions, you will always get the correct coloring results
for the colors that you DO have definitions for? Is it some claim on coins
which carry multiple colors? Sorry, I just don't get at all what that
section is trying to explain. The proof seems like a tautology, so I think
I'm just missing something.

5) Some minor questions/comments:

- In the diagrams, can you put quantities even for the uncolored boxes?
- Why do the uncolored boxes in the POBC diagram have padding?


Thanks,
Jeremy

[Alex Mizrahi]

Please remove my name/email from there.

I think this implies that I'm a co-author, but I definitely am not.

[Alex Mizrahi]

Note, inputs are simply value/color, because colorvalue is a derived property.

I'm afraid you're missing the context...

As you might remember, back in Spring we had problems with order-based coloring. Many alternative schemes were proposed, so I decided to describe the general model which can cover absolutely any Bitcoin-based smart property implementation with explicit dependencies.

(That is, colorvalues are fixed for a certain transaction. They depend only on transaction itself and not on its place in blockchain or anything like that.)

You can find the latest version of this model here:

https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

This is literally how the software (NGCCC) is implemented.

It is true that for OBC and POBC you can easily derive colorvalue from satoshi value, but these coloring schemes have problems with divisibility.

We already know how to implement parametrized color kernels which offer infinite divisibility

(although in practice we'll probably restrict it to 2^50 or so).

Also, it is important that each color is considered in isolation. The reason for this is that we cannot assume that client knows all colors.

This powerful model allows us to implement many different incompatible color kernels in one wallet without sacrificing reliability. We no longer care about bugs which can arise from interactions between different colors: they simply cannot happen.

 

I would hold off on introducing the concept of 'colorvalue' until after you have discussed the issues with OBC.

I do not think it is a good idea to use several different models, it can be confusing.

 

3) I was surprised at the increased complexity of POBC, because I think you can actually implement it much the same as OBC.

OBC has severe problems with backward scan coloring (it is the reason why we don't launch WebcoinX on the mainnet), POBC fixes these problems, making it more manageable for thin clients to discover coloring.

Yes, it is more complex, but who cares?

It isn't like we lack a capacity to implement a function which is whopping 20 lines long.

 

The algorithm in the whitepaper also has some side-effects I'm not sure are necessary, for example, if there are any inputs below the padding threshold at the start of the list, it will mark all outputs as uncolored.

This is by design.

 

I've implemented the algorithm in the whitepaper, as well as my own POBC which more closely aligns with OBC in the attached .js file and written some (very much not comprehensive) tests, and attached the test output as well.

Try implementing backward scan: for a given set of transaction's outputs, identify inputs colorvalues of which are necessary to compute outputs' colorvalues

 

4) I've read the 'Coloring Independence Theorum' repeatedly and I'm just not sure what it's trying to say.

FWIW I do not understand it either. I am not a co-author of Vitalik's paper.

[Jeremy Spilman]

That link definitely helps. :-) 

CK as you have defined it operates strictly on a single color, which is why returning simply 'colorvalue' is enough. If a transaction contains multiple colors, you have to run separate instances of CK on it.

Where you say "CK: (tx, tx_in_cvalues)->tx_out_cvalues" I would instead say "CKgold: (tx, tx_in_iscolored)->tx_out_iscolored" but it's pedantic.

This made my head spin for a minute, but certainly it's valid: "Input i is represented by a segment [a(i), b(i)] where a(0) = 0, a(i) = b(i-1), and b(i) = a(i) + svalue(i) - padding."

Here's how I would explain it back to you...

   We are given a list of input values, a list of output values, and a list of bits telling us which inputs are colored...

   Mark each input with the running sum of 'unpadded value' before and after that input's unpadded value is added into the sum. Do the same for outputs. So for each input and output you have a 'sumbefore' and a 'sumafter' value.

   Look for any span of inputs and outputs which start with the same 'sumbefore' and end with the same 'sumafter'.  If all inputs in the span are colored, then all outputs in the span are colored. Return a list of bits indicating which outputs are colored or not.

Of course it's easy to extend the definition to support multiple colors at once, or just iterate the function for each color.

I think the most important point is right at the end: "Most Bitcoin transactions which do not involve colored coins will have no matching input/output sequences, thus thin clients can abort backward scan as soon as they discover such transactions."

So the theory then is to tighten up the CK rules as much as possible without limiting real functionality, so backscans terminate more quickly. I can definitely see the benefit in that.

I implemented a version of POBC CK which follows that spec literally, and although it's not exactly obvious how it translates to the code that's in the whitepaper, it does behave the same for all my test inputs anyway.  See attached  PobcColorTransfer2 vs PobcColorTransfer3 if you're interested. Mostly I'm just playing around here.

One interesting behavior I found in all implementations is an output that lies within a segment which has (svalue == padding) and colorvalue == 0 is still considered colored. Probably this special case should not be considered colored, similar to how Bitcoin protocol technically supports output values of 0 but reference code will not relay them. You can see it in the last example in the attached results.txt.

Thanks,

Jeremy

On Thu, 14 Nov 2013 00:13:48 -0800, Alex Mizrahi <alex.m...@gmail.com> wrote:

You can find the latest version of this model here:

https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

This is literally how the software (NGCCC) is implemented.

[Alex Mizrahi]

CK as you have defined it operates strictly on a single color, which is why returning simply 'colorvalue' is enough. If a transaction contains multiple colors, you have to run separate instances of CK on it.

Yes, and this is how it is implemented too, e.g.:

https://github.com/bitcoinx/ngcccbase/blob/master/coloredcoinlib/colordef.py#L47

 

Where you say "CK: (tx, tx_in_cvalues)->tx_out_cvalues" I would instead say "CKgold: (tx, tx_in_iscolored)->tx_out_iscolored" but it's pedantic.

Yep, good point, I've been struggling with that. One of problems is that I used wiki rather than LaTeX.

 

This made my head spin for a minute, but certainly it's valid: "Input i is represented by a segment [a(i), b(i)] where a(0) = 0, a(i) = b(i-1), and b(i) = a(i) + svalue(i) - padding."

There is, indeed, a huge disconnect between mathematical definition and intuitive understanding.

But I think using this terminology (segments) is an improvement over old version which mentioned "preceding sums", as there is at least some hope that a person can visualize this.

I think illustrations could help this tremendously. 

Here's how I would explain it back to you...

Well, you described algorithm rather than what it is.

Of course, it is the same thing if it is correct, but I think it's good to have definition which can be used to validate algorithm.

 

So the theory then is to tighten up the CK rules as much as possible without limiting real functionality, so backscans terminate more quickly. I can definitely see the benefit in that.

Yes. 

I also hope that it makes backward scan code simpler, as otherwise it would have to consider all possible variants.

 

I implemented a version of POBC CK which follows that spec literally, and although it's not exactly obvious how it translates to the code that's in the whitepaper, it does behave the same for all my test inputs anyway.  See attached  PobcColorTransfer2 vs PobcColorTransfer3 if you're interested. Mostly I'm just playing around here.

Thanks, I'll check this.

By the way, are you interested in porting this code to Python so it can work in coloredcoinlib environment? (See the link above.) There are bounties for things like that, please let me know if you're interested.

 

One interesting behavior I found in all implementations is an output that lies within a segment which has (svalue == padding) and colorvalue == 0 is still considered colored.

Yes, I thought about this myself, I'm not sure about what to do with it.

 

Probably this special case should not be considered colored, similar to how Bitcoin protocol technically supports output values of 0 but reference code will not relay them.

This is no longer the case: zero-valued outputs are allowed by the upcoming version of bitcoind. (If they are provably unspendable.)

[Yoni Johnathan Assia]

This is awesome work Vitalik, and I am sure it will help the community a lot !

As a first draft comments from everyone are welcome, you can add comments in the doc itself.

--
You received this message because you are subscribed to the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Joshua Josh]

 This appears to be a summary or recapitulation of the original works by Meni Rosenfeld/Yoni Assia + a few revised ideas that sprung up here since they were published.

 Why aren't those original papers referenced?

 -bm

 

--

[paul snow]

Some of these algorithms either don't have good original papers, or I have never been able to find them.  I would like to second the idea that we add a reference section here, and provide links to interesting and informative writings on the topic in as much as they exist.

Paul

[Vitalik Buterin]

Made some changes. See the Google doc, or my version here:

 

http://vbuterin.com/coloredcoins/whitepaper.html

1) Added more sources

2) Added a modification/formalization of Paul Snow's coloring algorithm

3) Explained the consequences of the coloring theorem

4) Renamed "color transfer evaluation algorithm" -> ComputeOutputColors

5) Adopted a few other simplifications from the comments

6) Clarified that it will be expensive to issue a color with more than a few million units; we don't have a codified solution yet but if there is demand we will create it

[Yoni Johnathan Assia]

Great progress !
Are there directions in saving the color spec and genesis tx in the bitcoin block ?
I believe that could simplify the way to read colors and make sure that the color spec are secure and decentrelized as well.

--

[Joshua Zeidner]

 I found the original Color Coin whitepaper to be the most informative thing generated in this entire community.

 The fact that you don't bother to reference the historical dimension of this whole thing just subtracts from your credibility.

  -bm

[Yoni Johnathan Assia]

Bm,

Vitalik has been working together with everyone involved with this project from day 1, and has done a great job taking a lot of the work done so far and putting into one paper, after the last comment more refs have been added and more will be added too if needed.

Can u share what is the original one you reffer to ? The ond in the group header ?

Yoni

--

[BlueMeanie]

 hi Yoni,

   no idea where it went!  It was MLA style if I remember.

 -bm

[paul snow]

I am not putting down any of the papers written on the topic, but only pointing out I would like references to papers, as I have very likely missed significant papers.

If I left you with the impression that I intended to dismiss early writings, please accept this as a retraction. That wasn't my intended message.

Paul

--

[Alex Mizrahi]

   no idea where it went!  It was MLA style if I remember.

This one? http://bitcoil.co.il/BitcoinX.pdf

[BlueMeanie]

On Saturday, November 16, 2013 2:57:24 PM UTC-7, Alex Mizrahi wrote:

   no idea where it went!  It was MLA style if I remember.

This one? http://bitcoil.co.il/BitcoinX.pdf

looks familiar but I do recall double columns?

-bm

[Richard Brown]

Vitalik, All,

I thought I'd share some comments.

First, I think the doc is very well written; I really like it.  It sets out the problem space well and discusses only those Bitcoin features that are needed to support the narrative.  The first algorithm should probably be explained a little better as it assumes knowledge not explicitly introduced in the text above (although a reader can infer much, but possibly not all, of what they need from the accompanying diagram)

I wonder if one of the tests that should be applied to each coloring scheme is one of 'elegance' or 'architectural purity'?   e.g. what happens if the 5430 satoshi limitation goes away? Would that lead to a radically different solution?  If so, it's probably a sign that the solution under consideration is not ideal.    Perhaps the "non-restrictiveness" test covers this but I think there's a difference between "preserving freedom to act in the future" and "we'd do it differently if a constraint were lifted"

Possibly more controversial:   I don't know how many of you read Raymond Chen's blog (http://blogs.msdn.com/b/oldnewthing/) - I'd recommend it.  A lot of his content describes hacks Microsoft had to do in the Windows 3.1 days to work around limitations in the underlying architecture of DOS+Windows. He explains it really well and you end up with a greater appreciation for what they achieved given the constraints they faced (I'm sure not everybody will agree with me there....!)  I raise this because the discussions in the whitepaper about repurposing existing fields and hiding state in low-order bits reminded me very much of some of the tricks he described -- and it made me reflect that, in their case at least, what we were really seeing was evidence that their underlying architecture needed to be revamped (a move to the NT architecture in their case).

So I wonder whether what we're seeing here is the generation of a set of requirements for a Bitcoin 2.0 protocol - one that, perhaps, includes a layer of abstraction above the raw transaction data structures. That is: the reason why there are so many options for coin colouring, none of them ideal, could be because Bitcoin "1.0" isn't quite expressive enough.    Clearly, a switch isn't going to happen any time soon but I thought I'd share the parallel in case you found it interesting.

Richard

[paul snow]

Richard and All,

Being the author of one of the "hacks" mentioned (hiding state in low order bits), I would like to say that I very much agree with Richard here.  I learned programming on punch cards, and am quite versed in the art of squeezing information into tight spaces, largely from programming on those early DOS systems Richard mentions.

What would I like to change in the Bitcoin Protocol? I'd like more powerful scripting.  But that comes from being a Forth hack from the dawn of time.  

For Colored Coins, I would like an information value.  It could be selectable, perhaps 0, 8, 16, 32, or 64 bits.  With just that, the color signatures could be placed outside the Bitcoin value of the transaction. Even the number of colored coins to be transferred could be outside the bitcoin value of the transaction. Then all colored coin transactions would simply be the minimum transfer amount for the Bitcoin Network.  If that changes, nothing about colored coins would change.

Ultimately the power of using the Bitcoin Protocol to transfer value other than Bitcoin requires independence from Bitcoin itself.  An alt coin could do this quite handily of course, but leveraging the Bitcoin network has huge network advantages.

As a side note, I just left the day job to begin working on this and other Bitcoin projects full time.

Paul

--

You received this message because you are subscribed to the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Paul Snow

phone: (512) 627-8841

Fax:    (419) 831-9962 

skype: paulsnx2

[Joshua Josh]

On Fri, Nov 22, 2013 at 10:10 AM, paul snow <snow...@gmail.com> wrote:

Richard and All,

Being the author of one of the "hacks" mentioned (hiding state in low order bits), I would like to say that I very much agree with Richard here.  I learned programming on punch cards, and am quite versed in the art of squeezing information into tight spaces, largely from programming on those early DOS systems Richard mentions.

What would I like to change in the Bitcoin Protocol? I'd like more powerful scripting.  But that comes from being a Forth hack from the dawn of time.  

For Colored Coins, I would like an information value.  It could be selectable, perhaps 0, 8, 16, 32, or 64 bits.  With just that, the color signatures could be placed outside the Bitcoin value of the transaction. Even the number of colored coins to be transferred could be outside the bitcoin value of the transaction. Then all colored coin transactions would simply be the minimum transfer amount for the Bitcoin Network.  If that changes, nothing about colored coins would change.

Ultimately the power of using the Bitcoin Protocol to transfer value other than Bitcoin requires independence from Bitcoin itself.  An alt coin could do this quite handily of course, but leveraging the Bitcoin network has huge network advantages.

  The essence of the issue is that it's not 'leveraging' it's *exploiting*.  Some have already mentioned on the Bitcoin forums that they would not relay any transactions to the Mastercoin address.  While Color Coins isn't for-profit per se, and isn't as clearly offensive as Mastercoin, it does open up the door for exploitation.  Will we have miners who only relay Color Coins transactions for specific colors, that privilege certain transactions over others?  Will we have a massive processing power detente in order to achieve non-bias? 

  Some groups, especially large corporations who sell computer hardware might actually benefit from this detente in the same way arms manufacturers benefit from similar scenarios in the real military world.  Thus they might favor technologies which bring us to this scenario.  If these sorts of block chain abuses become commonplace, then the Bitcoin network will be forced to implement changes which compromise the p2p nature of the technology.

 -bm

 

[Yoni Johnathan Assia]

Hi Richard, Paul, and everyone,

I completely agree that all the projects which define new layers on top of the bitcoin protocol imply that there should be improvements to the existing protocol to support more functionality. The original mastercoin piece was actually names "the second bitcoin paper".

There is a good basis that some of the changes in the protocol, such as dust rules and txOut data store which facilitate better this type of projects while protecting the bitcoin network. 

Another layer of colored coins would be to create a /identity/reputation layer, so you could define based on a identity/reputation connected to addresses whether you would like to transact with that identity based on its history. This for example contradicts the anonymity paradigm of bitcoin, but adds significant features as majority of financial/economic transations are based on trust/history which is not represented today in the network. I will create an additional thread for this topic.

Yoni

[Alex Mizrahi]

I wonder if one of the tests that should be applied to each coloring scheme is one of 'elegance' or 'architectural purity'?

I'm afraid that would be inherently subjective... Usually when someone says that something is elegant, he can pinpoint particular traits which lead to elegance, so let's focus on them.

 

   e.g. what happens if the 5430 satoshi limitation goes away? Would that lead to a radically different solution?  If so, it's probably a sign that the solution under consideration is not ideal.

Yes, but it is actually captured by space-efficiency (size of transactions) and value-efficiency (i.e. doesn't require a lot of bitcoins to represent colored coins).

For example, if anti-dust limitation goes away, OBC becomes more efficient than POBC in terms of value-efficiency. 

But OBC is very problematic performance-wise (for a backward scan approach which will be employed by thin clients), so POBC wins anyway.

I think tagging-based schemes can win in terms of value-efficiency, and it is actually possible to have best space-efficiency at the same time, as was demonstrated by Peter Todd:

Vitalik's paper has inferior version of Todd's scheme (as we didn't understand the brief description Peter have provided).

Now I see that if it is implemented properly, it has both zero space overhead and also the best value-efficiency of all coloring schemes which use output values to encode quantity.

(Perhaps, "the best I can imagine" is more correct, I don't actually have a formal proof here.)

 

So I wonder whether what we're seeing here is the generation of a set of requirements for a Bitcoin 2.0 protocol - one that, perhaps, includes a layer of abstraction above the raw transaction data structures. That is: the reason why there are so many options for coin colouring, none of them ideal, could be because Bitcoin "1.0" isn't quite expressive enough.   

Bitcoin protocol allowed inclusion of arbitrary data in output scripts since day one (AFAIK), and we could use it to do coloring nicely: output script could refer to color id and quantity directly, and 'satoshi' value of it would be zero. (Output can be spent even if its value is zero.)

But the problem is that it is being discouraged by IsStandard rules: 'normal' Bitcoin nodes won't forward such transactions, and few pools allow them into blocks. (E.g. Eligius pool.)

So it is not so much a problem with a protocol as it is a "problem" with a policy chosen by Bitcoin core developers.

However, it is worth noting that resorting to various tricks allows us to achieve higher space efficiency.

As for 'Bitcoin 2.0', of course, it would be interesting to see a native implementation of features provided by colored coins, but the problem is that once such protocol is implemented, it's no longer possible to add features or choose different trade-offs.

For example, Freimarkets proposal

http://freico.in/docs/freimarkets-v0.0.1.pdf

includes many interesting features, but also:

1. It is fairly complex, and thus it might introduce new problems.2

2. It isn't particularly concerned about space efficiency

3. Even though it's feature-rich, it cannot provide all features colored coins might provide.

A different approach would be to use a more powerful scripting language, but I'm afraid it will be viable only if SCIP (Succinct Computational Integrity) is used for script validation. And that would make it much more complex.

On the other hand, colored coins allow us to 'inject' new rules into existing system in a structured and contained. Which, I think, is a great way to experiment with new features.

It can be likened to 'fuse' in Linux: of course, it is more efficient to have a proper filesystem impleemntation in kernel,

but in some cases, userspace implementation via fuse is acceptable and even is beneficial, as it cannot crash the whole system, for example.

[Alex Mizrahi]

For Colored Coins, I would like an information value.  It could be selectable, perhaps 0, 8, 16, 32, or 64 bits.  With just that, the color signatures could be placed outside the Bitcoin value of the transaction. Even the number of colored coins to be transferred could be outside the bitcoin value of the transaction. Then all colored coin transactions would simply be the minimum transfer amount for the Bitcoin Network.  If that changes, nothing about colored coins would change.

Bitcoin protocol already allows this, but it is discouraged on mainnet.

You can do it this way on testnet, and perhaps you'll be able to convince core devs to bless enable it on mainnet. (Well, good luck with that...)

[Alex Mizrahi]

  The essence of the issue is that it's not 'leveraging' it's *exploiting*.

What's about 'distributed contracts' listed here:

https://en.bitcoin.it/wiki/Contracts

Do they leverage or exploit the system?

[Dominik Zynis]

Very nice work Vitalik.

Regarding your last paragraph could a seperate blockchain network act as an escrow service in a 3 part multisig tx? Sorry if I speak at a very abstract level. The escrow network is given the pub keys for the 2 traders, and shares a unique pubkey for the tx to the traders, all three parties broadcast a send tx into bitcoin network. The escrow network would only brosdcast once it sees brosdcasts from the other two parties.

Kind of sounds like msc, but in this case miners could get paid out for escrow processing, and doing the 3rd send tx. So maybe 6 sigs are needed, 3 for each network...

Of course the enforcability of trade happens only if all parties have actually broadcast their tx. But in real life if I pull out of a deal at the last minute before the contract is signed, there is no contract :)

Perhp I missed something and am oversimplifying.

[Dan Miller]

Are projects that use a separate blockchain and network than bitcoin the bitcoin blockchain and network, such as "freimarkets" http://freico.in/docs/freimarkets-v0.0.1.pdf in scope for this discussion?