ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..

[vokain]

During my one comp sci class, I think I learned that the majority of work (at least cost of time wise) involved testing. I'd like to encourage this somehow to have more help on the testing front. Bug bounties a la google et al to preserve a rigorous spec.

[zathras]

During my one comp sci class, I think I learned that the majority of work (at least cost of time wise) involved testing. I'd like to encourage this somehow to have more help on the testing front. Bug bounties a la google et al to preserve a rigorous spec.

Couldn't agree more on encouraging more testing - there is 100BTC ($100k+ as of right now, even Google max out at $20k for the most severe bugs) already in bounties for incentivising testing.

[killerstorm]

For clarity though we don't have anything 'stable' - not even close.  Rapid prototyping (RAD) is the order of the day for now.

This is what I was talking about.

In case with colored coins, each color is independent, and can be fairly simple. It's trivial to "feature freeze" a color (at least in terms of ownership), and then, technically, there might be bugs in wallet implementation, but semantics is 100% clear.

But Mastercoin is monolithic and feature-full. Each feature can potentially interact with each other. Getting a stable Mastercoin implementation with sane upgrade policy is very hard IMHO.

I hope you do not recommend people to trust their money to something which "don't have anything 'stable' - not even close" and is in "rapid prototyping" stage.

So I said that we'll likely get a usable colored coins usage way before usable Mastercoin exchange. But Ron and Taariq pretend that it's non-issue, like, we have a spec on github, hence consensus is guaranteed.

Really? This spec is nothing. It is way too vague. You haven't even tried to formalize interpretation of the spec or anything like that.

For example, it defines that rate-limited address cannot be used for decentralized exchange. This makes sense, of course.

But what if a command to make address rate-limited is sent after an offer on decentralized exchange is made? Will it cancel the offer, or will command be ignored?

If implementation X cancels the offer, while implementation Y ignores a command to make address rate-limited, it is possible to double-spend.

You need to define a formal model of Mastercoin transactions, e.g. a state variables are associated with each address. And then you can describe how each command modifies state variables of addresses which are involved.

I would completely agree that the Bitcoin core dev team likely do have more structure and rigorousness applied, but that's a project (worth multiple billions) that has had ~5 years to get to this point - I believe a startup phase looks different but that's just my view.

Actually, no: Satoshi released a complete version of a client, and Bitcoin developers were always reluctant to change things which can affect consensus. Almost no features were added to the protocol in these 5 years. If anything, many features were disabled.

[killerstorm]

During my one comp sci class, I think I learned that the majority of work (at least cost of time wise) involved testing.

Well, you need something to test it against, so you need a formalized model and spec first.

[vokain]

During my one comp sci class, I think I learned that the majority of work (at least cost of time wise) involved testing.

Well, you need something to test it against, so you need a formalized model and spec first.

How did it work with HTTP dev? I'm not familiar. (Actually, was how that was developed even relevant to us?)

[zathras]

For clarity though we don't have anything 'stable' - not even close.  Rapid prototyping (RAD) is the order of the day for now.

I hope you do not recommend people to trust their money to something which "don't have anything 'stable' - not even close" and is in "rapid prototyping" stage.

Not at all, I do believe the Mastercoin community understand the message that as of the time of this posting, simple sends are the only safe and 100% supported way to transfer Mastercoins.  

I have a working wallet right now which it could be in my financial interest (ie better my position in the contest) to release sooner & get everyone using it but there are still discussions happening around certain specifics and not all implementations yet agree on DEx states - when we're done and we have consensus among all devs & implementations, then I'll think about releasing.

Note, I'll be doing limited releases to the other devs and some of the board members, but that's only for testing & comparison purposes at this stage.

So I said that we'll likely get a usable colored coins usage way before usable Mastercoin exchange. But Ron and Taariq pretend that it's non-issue, like, we have a spec on github, hence consensus is guaranteed.

I've made it a rule to try not to get involved in discussions comparing Mastercoin to other projects, simply because it's impossible for me to be objective on such a topic.

Really? This spec is nothing. It is way too vague. You haven't even tried to formalize interpretation of the spec or anything like that.

Whilst I do agree the spec has areas that need clarity and further defining, I don't think I'd agree with the statement that we aren't trying to formalize the spec.  Where we come across areas of ambiguity a consensus is reached between the devs with the idea that decision is then locked into the spec.

This is done in an incremental fashion, rather than all-at-once however, and perhaps that contributes to your perceived lack of control.  From my experiences to date the process has largely been to define a 'feature', prototype it, compare across (4 I think it is now) independent implementations, discuss areas of ambiguity / differing interpretations of the spec / differing states in the various implementations, define / clarify / lock-in those issues so we have a clear set of rules we all agree on and code to.

For example I took on transaction storage as my first real push for a spec amendment (I thought it fairly fundamental) - there was lots (and lots) of discussion and once I was happy we all agreed on all the necessary bits I wrote an appendix and asked JR to include it in the spec, which he did here.

TL:DR; I believe the spec will continue to be formalized with each feature rather than all at once.

For example, it defines that rate-limited address cannot be used for decentralized exchange. This makes sense, of course.

But what if a command to make address rate-limited is sent after an offer on decentralized exchange is made? Will it cancel the offer, or will command be ignored?

If implementation X cancels the offer, while implementation Y ignores a command to make address rate-limited, it is possible to double-spend.

Understood, and this essentially reflects my comments above - that's the type of question that gets identified as an area of ambiguity, raised during prototyping said feature, discussed, agreed and a decision made & locked in.

I would completely agree that the Bitcoin core dev team likely do have more structure and rigorousness applied, but that's a project (worth multiple billions) that has had ~5 years to get to this point - I believe a startup phase looks different but that's just my view.

Actually, no: Satoshi released a complete version of a client, and Bitcoin developers were always reluctant to change things which can affect consensus. Almost no features were added to the protocol in these 5 years. If anything, many features were disabled.

I actually didn't know Satoshi released a complete client along with the white paper - I thought (assumed) that came later.  I wasn't around for the beginning of the cryptocurrency revolution sadly!

Personally I will say I see huge potential in Mastercoin - that's why I got involved in the first place.  I think the features it targets are exactly the kinds of things needed to attract big finance/corporate to cryptocurrencies.  


I should also say that that's just my personal take on the points you've raised.  This is just how I've chosen to approach things as an individual.  My views are my own and may not necessarily reflect those of the foundation/project. etc etc.

JR/Ron/Taariq would need to comment for any formal/official views.

Thanks again for the feedback

[Meni Rosenfeld]

I would completely agree that the Bitcoin core dev team likely do have more structure and rigorousness applied, but that's a project (worth multiple billions) that has had ~5 years to get to this point - I believe a startup phase looks different but that's just my view.

Actually, no: Satoshi released a complete version of a client, and Bitcoin developers were always reluctant to change things which can affect consensus. Almost no features were added to the protocol in these 5 years. If anything, many features were disabled.

I actually didn't know Satoshi released a complete client along with the white paper - I thought (assumed) that came later.  I wasn't around for the beginning of the cryptocurrency revolution sadly!

It's true (and doesn't seem to contradict what killerstorm said) - Satoshi released the whitepaper in October 2008, and then the client in January 2009. But other than a few comments nobody actually did anything with the whitepaper.

[killerstorm]

Not at all, I do believe the Mastercoin community understand the message that as of the time of this posting, simple sends are the only safe and 100% supported way to transfer Mastercoins.

I doubt people understand understand what it actually means...

I'll post an example into the main mastercoin thread.

[killerstorm]

I want to make a demo version. There is a couple of options in terms of requirements:

1. testnet / mainnet
2. requires local bitcoind / requires nothing
3. requires bitcoind with txindex / doesn't require txindex
4. does full scan / works without full scan

The problem is, most secure and straightforward option (bitcoind with txindex, full scan) is also slowest and most cumbersome to setup.

I'd like to know what people would like to test.

Of course, eventually one would be able to choose what to run in config, and all of them will be secure, but currently we need to focus on something specific.

[kslaughter]

I want to make a demo version. There is a couple of options in terms of requirements:

1. testnet / mainnet
2. requires local bitcoind / requires nothing
3. requires bitcoind with txindex / doesn't require txindex
4. does full scan / works without full scan

The problem is, most secure and straightforward option (bitcoind with txindex, full scan) is also slowest and most cumbersome to setup.

I'd like to know what people would like to test.

Of course, eventually one would be able to choose what to run in config, and all of them will be secure, but currently we need to focus on something specific.

I think testnet/local bitcoind with txindex/full scan.

[t3a]

One question I've had about colored coins.

What happens if an address has a colored coin with an arbitrary value as an input and another non-colored input with arbitrary value, then I make a transaction with two outputs. Who gets the colored coin between the two outputs?

[killerstorm]

What happens if an address has a colored coin with an arbitrary value as an input and another non-colored input with arbitrary value, then I make a transaction with two outputs. Who gets the colored coin between the two outputs?

Transaction needs to be made with the special software. If you somehow use a normal Bitcoin client, colored coins will get lost. (Neither of two outputs will get it.)

[t3a]

What happens if an address has a colored coin with an arbitrary value as an input and another non-colored input with arbitrary value, then I make a transaction with two outputs. Who gets the colored coin between the two outputs?

Transaction needs to be made with the special software. If you somehow use a normal Bitcoin client, colored coins will get lost. (Neither of two outputs will get it.)

I see, so a colored coin always has only one output?

[killerstorm]

I see, so a colored coin always has only one output?

No, it can be split into many outputs, but transaction shall be created according to the rules. E.g. colored outputs should be grouped together.

[killerstorm]

We're hiring testers

NGCCC is more-or-less ready now, but we'd like to do some testing internally before releasing it to public. So we're looking for testers.

I'd like to work with tech savvy testers who both understand what software does and aren't afraid of tech stuff like Linux, VM, command-line, etc. Programming experience isn't required, but can be a bonus.

If interested, please PM me and describe what you can do and what compensation you expect.

Also looking for tech writers to write docs.

[dillpicklechips]

We're hiring testers

NGCCC is more-or-less ready now, but we'd like to do some testing internally before releasing it to public. So we're looking for testers.

I'd like to work with tech savvy testers who both understand what software does and aren't afraid of tech stuff like Linux, VM, command-line, etc. Programming experience isn't required, but can be a bonus.

If interested, please PM me and describe what you can do and what compensation you expect.

Also looking for tech writers to write docs.

Make sure to advertise here if no one replies:

http://www.reddit.com/r/Jobs4bitcoins
https://bitcointalk.org/index.php?board=52.0

[killerstorm]

Only for 64-bit Linux:

http://killerstorm.xen.prgmr.com/alex/ngccc-0.0.1-linux-x86_64-2.7.tar.bz2 (EDIT: this isn't the latest version)

p2ptrade doesn't work properly, this build is just to check whether it
works in general.

You need local bitcoind to run it.
1. on testnet, it requires txindex
2. on mainnet, it might work without txindex, but is faster with txindex

Here's how to set it up on testnet:

1. run bitcoind or bitcoin-qt with txindex, e.g:
    ./bitcoind -testnet -txindex -daemon
    If you previously ran it without txindex, you need to use reindex
option one time only:
    ./bitcoind -testnet -txindex -reindex -daemon
    Wait until it downloads/reindexes blocks.

2. Configure ngcccbase to use testnet:
   ./ngccc-cli setval testnet true

4. From now you can use either command-line version:
    ./ngccc-cli --help
   Or GUI:
    ./ngccc-gui

5. If you need several instances, it's better to copy whole ngccc
directory and delete wallet.db in the copy so new wallet will be
created.
   (It is also possible to use different wallet files, e.g.
./ngccc-cli -wallet=testnet.wallet, but it doesn't work properly if
you use them simultaneously due to color.db locks.)

[NuclearReactor]

Only for 64-bit Linux:

http://killerstorm.xen.prgmr.com/alex/ngccc-0.0.1-linux-x86_64-2.7.tar.bz2

p2ptrade doesn't work properly, this build is just to check whether it
works in general.

You need local bitcoind to run it.
1. on testnet, it requires txindex
2. on mainnet, it might work without txindex, but is faster with txindex

Here's how to set it up on testnet:

1. run bitcoind or bitcoin-qt with txindex, e.g:
    ./bitcoind -testnet -txindex -daemon
    If you previously ran it without txindex, you need to use reindex
option one time only:
    ./bitcoind -testnet -txindex -reindex -daemon
    Wait until it downloads/reindexes blocks.

2. Configure ngcccbase to use testnet:
   ./ngccc-cli setval testnet true

4. From now you can use either command-line version:
    ./ngccc-cli --help
   Or GUI:
    ./ngccc-gui

5. If you need several instances, it's better to copy whole ngccc
directory and delete wallet.db in the copy so new wallet will be
created.
   (It is also possible to use different wallet files, e.g.
./ngccc-cli -wallet=testnet.wallet, but it doesn't work properly if
you use them simultaneously due to color.db locks.)

I have no idea what I'm doing. Here is a screenshot.

http://imgur.com/z8jaAYa

Ubuntu 13.10 64-Bit

[killerstorm]

I have no idea what I'm doing. Here is a screenshot.

http://imgur.com/z8jaAYa

Ubuntu 13.10 64-Bit

If you're using Bitcoin-Qt instead of bitcoind, you need to enable RPC interface in config:

~/.bitcoin/bitcoin.conf

Code:

server=1
rpcuser=rpcuser
rpcpassword=somepasswordhere

(you might want to edit rpcpassword part). Create this file and restart bitcoin-qt. (Note that you don't need -reindex option, but you need other options... Except -daemon, it is useless in this case.)

[NuclearReactor]

I have no idea what I'm doing. Here is a screenshot.

http://imgur.com/z8jaAYa

Ubuntu 13.10 64-Bit

If you're using Bitcoin-Qt instead of bitcoind, you need to enable RPC interface in config:

~/.bitcoin/bitcoin.conf

Code:

server=1
rpcuser=rpcuser
rpcpassword=somepasswordhere

(you might want to edit rpcpassword part). Create this file and restart bitcoin-qt. (Note that you don't need -reindex option, but you need other options... Except -daemon, it is useless in this case.)

Oh, I had the config file, just didn't have a server entry. Got it running. Now what? Sent you a PM.

http://imgur.com/rPkgT1Z