Will this support colored coins format from the start ?
I think that's an amazing differentiator.
Website launched, I am adding documentation and background info: http://bitsofproof.com
--
You received this message because you are subscribed to the Google Groups "Colored bitcoin - BitcoinX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I would say, your style is completely broken.
My code, since fresh has bugs and might be in disagreement with yours.
I am glad if you pinpoint bugs, so I fix it. A bug is however not defined by disagreement with your implementation,we have enough of that shit in this community.
We need test vectors not sacred implementations.
I will create test vectors and you might have some. Hopefully we comeup with a suite that proves that an implementation is compliant and I promise you to run that with every pull of bits of proof.
I agree specifying some test cases is the way to go to advance in
standardizing the coloring rules.
There is likely no disagreement on the rules, we will clarify in a conference this week.I was just pissed by tone how bits of proof implementation was dismissed.
The implementation of the coloring rulesis a small fraction of the work I put into this and more than likely it can be fixed if it was not in alignment withexpectations.
I know the rules are specified, i meant standardizing the different "non-official rules" that each implementation may have by making them comply with the same set of "standard tests". Does this make more sense to you?
It can be a simple set of tests that make sure you comply with the specification and grow when more edge cases appear or when the specifications change to support new features or because we realize we missed something (I'm not saying it is the case, just trying to imagine possible reasons to extend these "standard tests").
--
I know the rules are specified, i meant standardizing the different "non-official rules" that each implementation may have by making them comply with the same set of "standard tests". Does this make more sense to you?
It can be a simple set of tests that make sure you comply with the specification and grow when more edge cases appear or when the specifications change to support new features or because we realize we missed something (I'm not saying it is the case, just trying to imagine possible reasons to extend these "standard tests").
I mean subtle differences between the algorithms (maybe trying to support more features or just implementation differences) that don't break the general rules and therefore aren't necessarilly bugs.
Anyway, whatever the reasons, designing those tests can only be a good thing and I'm glad we can all agree on that.
As you said before, they're not a substitute of the specificaions but rather a complement.
--
Defining these test is a great idea ! The actual standard can be defined as test driven development and simlly define thos set of test, and have automatic scripts to test differemt implementations.
Can someone help write thise tests ?
Thanks,
Yoni
Tamas has worked hard to get something working. Any normal project would be very happy with such commitment. The code is of good quality and instead it is trashed after a small review.
Alex is right on every aspect, except for subtility. It's all about the process.
--
Alex, I'd love to respond but at this point I need more knowledge. My previous opinion was just about the process, but to have an opinion about the coloring algorithm I need to learn about the bitcoin protocol, which I'm going to do now.
But for this project you need a high-quality standard (because of the cost of a bug and because the code will be inspected millions of times when things get rolling). This means we need a different process. Every single java statement will need discussion before it ends up in a Java file. Of course we'll need tests as well, but that's just a side thing.
We start from scratch with the code.
I'm planning to invest at least 2 months in this project starting today.
I've got only one small other project running. In addition, if my advice is followed upon exactly AND everybody stays onboard, I'll invest 3 BTC to this project today. I see it as a commerical investment, and I will want a share of the proceedings. (Or if I decide to quit the project, I'll want the 3 BTC back once the proceedings are there). I know this doesn't sound like a lot, but please beware that I only found out about bitcoins very recently and this is a huge portion of the bitcoins I own.
Alex, I'm not good with terminology and definitions.
But I do understand that you give a way to DEFINE coloring, and that that description should not be taken as an implementation prescription at all. (I'm deliberately avoiding the word "algorithm" here, everybody seems to have his own definition of it.)
I have looked at your js code. We have to be careful with the MIXED value, because it's not defined in your document. My suggestion would be to declare the transaction illegal instead (when now a MIXED would be encountered). An alternative would be to uncolor the satoshi, which is something we don't really want to happen either.
The last alternative I see is to really have a linear combination of colors in one output. But that would lead to improper definition of colors when that output becomes an input in a new transaction. Of course it depends on the practical implications whether we can/should use this alternative. If I understand everything about the bitcoin protocol right, it would make sense to me to always have a separate wallet for each color (I think?) at client's responsibility, which would render this last alternative unnecessary.
--
It can be made mathematically much more beautiful and easier to implement. We don't need "color definitions". With an easy adjustment, a satoshi could have multiple colors (but not a linear combination; each color is yes or no). Every output is a genesis. Most of them are irrelevant. The only thing you want to know is: "is my wallet of color x"? It works almost the same as Alex's article except that you would now need to backtrack instead of doing it bottom-up.
Obviously at some point we will want color definitions. As in: what can I do with pink satoshi? But I don't see why we would need to specify that at this point. We don't need a format for it yet: we can trade although it's not user friendly.
Note that I'm confusing the terms "wallet" and "transaction output". This is because I don't know the exact difference. I suppose a wallet contains a set of transaction outputs?
Now I'm beginning to understand why we need to adjust some wallets source code. I was hoping we could make a "proxy" on top of a wallet, but that might be impossible as a general wallet would mix the colors.
So I agree that the question is now, what are we going to use as basis? We can't make it general for any wallet. The options you mention are bitsofproof, armoryX and MultiBit.
I will now delve further into the bitcoin protocol to figure out if two parties can make a trade where they cannot fool each other and if wallets would almost support something like that (i.e. coins going into 2 directions).
Obviously at some point we will want color definitions. As in: what can I do with pink satoshi? But I don't see why we would need to specify that at this point. We don't need a format for it yet: we can trade although it's not user friendly.
>Color definitions are necessary because people want to be able to issue more coins of same color...>Otherwise, yes, it is a matter of user interface.
I think I'm going to stick with my point here. Your backward scan implementation is not what I mean: it returns the color. The backward scan I'm talking about would check if a coin has a given color x (true or false). It could return true for more than one color.
The color definition makes things unnecessarily complicated.
We will need it in the end, but in your setup we would need it for the protocol to work properly.
It's like the http protocol requiring nameservers to function.
If someone wants to issue more coins of a certain color (and didn't create and store extra in the first place), he should just issue another color and provide a 1->1 service instead. In short: every output is a genesis. It will make life much easier.
Well, almost... Transactions with same hash are actually possible, so you might be better off with block number and index within block
Actually the main problem I see with bitsofproof is that it requires color to have terms, signature and pubkey:
Your countless emails and self referencing documents are not binding to my creativity for the same reason:
they have no proven uses yet.
Well, almost... Transactions with same hash are actually possible, so you might be better off with block number and index within blockWrong. See https://en.bitcoin.it/wiki/BIP_0030 (BIP30)Transaction hashes are unique on the trunk.
A color without terms is meaningless in my opinion.
--
I think we have a different view on what is a color wrt a certain aspect. You see a color as something that's an asset group, whereas I see it as something that should exist naturally. We can decouple this!I'd like to name my color "colorSingle". It's the colors that exist naturally by having single-genesis. There can never be misconception about what colorSingles a certain output is. Let's call your color "colorAsset". a colorAsset is simply a set of colorSingle.Yes I know, there's a subtle difference between your definition of a color and colorAsset. Would you give in a little bit here for the sake of decoupling? This is the example:
transaction2:in1: colorSingleBrownin2: colorSingleRedout1: colorSingleRedout2: colorSingleBrown
--
This sort of creates for colored coins the ability to work like ripple in a decentralized way, for every asset you "trust" specific set of issuers.I believe this is something that color coins should support, as having multiple issuers significantly makes the p2p exchange more liquid and more decentralized.
This is amazing ! We can have a decentrelized exchange with decentrelized issuers as well, this means we can create real alts based on colored coins.
--
--
I believe that I addressed incompatibilities or bugs previously spotted by Alex definition. Let me please know if not.
PS(input[i]), PS(input[i])+input[i].value]
and[PS(output[j]), PS(output[j])+output[j].value]
overlap.I focus at server trusting client at the moment, therefore a different knowledge of colors is not a concern.