Bitcoin Forum
March 19, 2024, 08:02:09 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 28 »
  Print  
Author Topic: ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..  (Read 96870 times)
Flavien
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
November 14, 2013, 04:20:25 PM
 #281

And to me, the only way colored coin will take off is by getting partners willing to emit colored coins by backing them with real assets. Bitstamp for instance could emit USD colored coins, since they already do that with Ripple.

Well, currencies isn't the only use case for colored coins. In fact I see more interest for capital market use cases.

But there are also people/companies interested in what you described above.

There are two possibilities if you want to use colored coins for securities:
1: The security is not native to the blockchain (such as an AAPL stock), in which case, everything I said applies. You need to be able to redeem your colored coin for an actual AAPL stock. That will only happen when stock brokers decide to support colored coins, which is way down the road (will happen much later than my use case with Bitstamp and USD).
2: The security is native to the blockchain, let's say someone decided to go public with their company and emit shares on the blockchain, but the challenge is making sure that "colored coin as equity" is recognized by the law (given the amount of regulation around that, it's fair to say it's not).
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
According to NIST and ECRYPT II, the cryptographic algorithms used in Bitcoin are expected to be strong until at least 2030. (After that, it will not be too difficult to transition to different algorithms.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
1710835329
Hero Member
*
Offline Offline

Posts: 1710835329

View Profile Personal Message (Offline)

Ignore
1710835329
Reply with quote  #2

1710835329
Report to moderator
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 14, 2013, 04:34:20 PM
 #282

1: The security is not native to the blockchain (such as an AAPL stock), in which case, everything I said applies. You need to be able to redeem your colored coin for an actual AAPL stock. That will only happen when stock brokers decide to support colored coins, which is way down the road (will happen much later than my use case with Bitstamp and USD).

Have you ever heard about CFDs?

http://www.etoro.com/

2: The security is native to the blockchain, let's say someone decided to go public with their company and emit shares on the blockchain, but the challenge is making sure that "colored coin as equity" is recognized by the law (given the amount of regulation around that, it's fair to say it's not).

ActiveMining considers doing that. As for legality, it's definitely not worse than shares on BitFunder or "direct shares".

I think if company is a scam, it will find a way to scam you even if contract is recognized by law. And if it isn't a scam...

Chromia: a better dapp platform
tiaguitah
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
November 17, 2013, 09:26:41 PM
 #283

any new progress on colored coins? :p

killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 17, 2013, 09:46:28 PM
 #284

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

Chromia: a better dapp platform
kslaughter
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250



View Profile WWW
November 17, 2013, 11:18:31 PM
 #285

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

Are they padded?
TKeenan
Hero Member
*****
Offline Offline

Activity: 874
Merit: 1000



View Profile
November 17, 2013, 11:40:21 PM
 #286

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.
I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 17, 2013, 11:40:32 PM
 #287

Are they padded?

No, currently only simple OBC is implemented. It's enough for the demo/testing of other components.

We consider several coloring schemes. The one designer by Peter Todd looks even more promising than POBC, but it's not finalized yet.

In any case, adding a coloring scheme isn't a big deal because they are self-contained. (Basically, each one is a separate class.)

Chromia: a better dapp platform
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 17, 2013, 11:46:22 PM
 #288

I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
3. The problem with Mastercoin is lack of finalized specification. Difference between multiple implementation can result in monetary loss. On the other hand, in case with colored coins, an implementation of color kernel can serve as a finalized specification: you can just keep using it, it will never change. We can implement other kernels, but they do not invalidate older kernels, different kernels can peacefully co-exist.

Chromia: a better dapp platform
dillpicklechips
Hero Member
*****
Offline Offline

Activity: 994
Merit: 507


View Profile
November 18, 2013, 06:17:26 AM
 #289

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.
I can't wait to see it! I'm glad things are accelerating for you!
HostFat
Staff
Legendary
*
Offline Offline

Activity: 4200
Merit: 1202


I support freedom of choice


View Profile WWW
November 18, 2013, 08:40:40 AM
 #290

Yup! I also want to see it Smiley

NON DO ASSISTENZA PRIVATA - http://hostfatmind.com
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 21, 2013, 01:56:22 PM
 #291

p2ptrade GUI screenshot: https://i.imgur.com/VlVw6cT.png

(it needs some bugfixes/improvements to work properly, though.)

Chromia: a better dapp platform
ripper234
Legendary
*
Offline Offline

Activity: 1358
Merit: 1003


Ron Gross


View Profile WWW
November 22, 2013, 11:56:02 PM
 #292

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
3. The problem with Mastercoin is lack of finalized specification. Difference between multiple implementation can result in monetary loss. On the other hand, in case with colored coins, an implementation of color kernel can serve as a finalized specification: you can just keep using it, it will never change. We can implement other kernels, but they do not invalidate older kernels, different kernels can peacefully co-exist.

2. We're pushing forward our securities / Smart Property feature. We just hired Taariq Lewis to lead that effort, and are gearng up to accelerate both the bizdev and coding.

3. What do you mean "finalized spec"? We are evolving and adding new features all the time (spec is on github) - how is that bad? We have a spec for Smart Property already in v1.1 of the spec, but are open to modifications / bug fixes if needed, and are coordinating the information flow between all the developers.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 23, 2013, 01:29:10 AM
 #293

3. What do you mean "finalized spec"? We are evolving and adding new features all the time (spec is on github) - how is that bad? We have a spec for Smart Property already in v1.1 of the spec, but are open to modifications / bug fixes if needed, and are coordinating the information flow between all the developers.

Do you understand a concept of hard fork? Each update to a set of rules needs to be done in such a way that all clients will be updated before new rules are in effect.

If two client implementations can disagree about a results of a transactions, it might be used for double-spending.

If you do not have an update schedule, clients will be updated at random points and they WILL disagree.

This is what I meant by "finalized spec": you have to do a feature freeze at some point if you want Mastercoin do be secure.

Chromia: a better dapp platform
tlewis
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile WWW
November 23, 2013, 02:17:29 AM
 #294

I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
[snip]


Unfortunately, #2 is incorrect. The Mastercoin distributed exchange goes well beyond the trading of securities to include any particular asset.

Quote
"Mastercoin supports creating property tokens to be used for titles, deeds, user-backed currencies, and even shares in a company. Whenever property is created, it gets assigned the next available currency ID, so any property can be bought, sold, transferred, and even used for betting, just like other Mastercoin-derived currencies."
Source: https://github.com/mastercoin-MSC/spec#smart-property

I'll be adding more details around the opportunities on this functionality in blog posts coming up and would definitely like to continue to explore the contrasts between Mastercoin and Colored Coins.
ripper234
Legendary
*
Offline Offline

Activity: 1358
Merit: 1003


Ron Gross


View Profile WWW
November 23, 2013, 06:20:01 AM
 #295

Do you understand a concept of hard fork? Each update to a set of rules needs to be done in such a way that all clients will be updated before new rules are in effect.

If two client implementations can disagree about a results of a transactions, it might be used for double-spending.

If you do not have an update schedule, clients will be updated at random points and they WILL disagree.

This is what I meant by "finalized spec": you have to do a feature freeze at some point if you want Mastercoin do be secure.

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
overcoin
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
November 23, 2013, 08:26:56 AM
 #296

Nice work.
Following.
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 23, 2013, 12:06:27 PM
 #297

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Cryptocurrency is secure only under condition that there is a consensus among all clients. If you cannot guarantee that, that means that cryptocurrency you're developing isn't secure.

By "guarantee" I mean that you can prove that problem like that cannot happen under certain assumptions. Of course, bugs are possible, but you need to demonstrate that you're doing the best effort to prevent problems.

If you're piling on features instead of implementing secure update mechanism that means that security is a low priority for you.

I think this problem was brought up many time before, I don't see why it is news for you.

Chromia: a better dapp platform
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
November 27, 2013, 10:26:31 AM
 #298

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Cryptocurrency is secure only under condition that there is a consensus among all clients. If you cannot guarantee that, that means that cryptocurrency you're developing isn't secure.

By "guarantee" I mean that you can prove that problem like that cannot happen under certain assumptions. Of course, bugs are possible, but you need to demonstrate that you're doing the best effort to prevent problems.

If you're piling on features instead of implementing secure update mechanism that means that security is a low priority for you.

I think this problem was brought up many time before, I don't see why it is news for you.

Hey Killerstorm,

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

FYI from our internal discussions regarding hardforks:
Quote
Can anyone think of any scenarios where such an action would be required in an uncontrolled manner?

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

A perfect example of this was adding obfuscation to Class B - this would have been very different with backwards compatibility etc being built if there had been non-obfuscated transactions out in the wild, but since we thoroughly vetted it was just Tachikoma & my test transactions we could safely drop support without any impact and there was no change control variant needed.

This is one of the core reasons I've been quite restrictive with my releases of late, because I want to make sure we're all on the same page decoding/validation wise as changing something after the fact when its in the hands of users under real world usage would be a lot harder to manage.  

Cheers
Zathras


Smart Property & Distributed Exchange: Master Protocol for Bitcoin
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
November 27, 2013, 11:32:11 AM
 #299

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

Sorry, I don't think you understood me.

Suppose you have two branches of your application: stable and testing. Each branch goes through a number of versions, e.g. zathras.stable.3, zathras.testing.7.

Other developers do the same: they have two branches: stable and testing. Suppose there is version called Tachikoma.stable.7.

Now we can formulate a condition: if there are xxx, yyy, i and j such that: xxx.stable.i disagrees with yyy.stable.j, and there is a possibility that user A uses xxx.stable.i while user B uses yyy.stable.j, it is a very serious fuck up.

Note that this means that if your old version, let's call it zathras.stable.2 disagrees with some new version released by Tachikoma, let's say Tachikoma.stable.7, it is a fuck up.

How is it even possible to do this without fuck ups?

You should tie it to block numbers. Let's say zathras.stable.3 works only until block 275000, after that it tells user that he should upgrade. This means that if you want to update rules in a stable branch, new rules should be applicable since block 275001.

Of course, you don't need to be that rigorous with testing branches, but at some point you'll need to produce stable versions.

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

Sorry, but you have no idea what "hard fork" means.

Look, I'm not nitpicking, I'm trying to help. There is a huge disconnect between level of rigorousness applied by Bitcoin core dev team and Mastercoin developers.

It looks like you do not understand the consequences.

Chromia: a better dapp platform
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
November 28, 2013, 07:40:28 PM
Last edit: November 28, 2013, 08:28:06 PM by zathras
 #300

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

Sorry, I don't think you understood me.

Suppose you have two branches of your application: stable and testing. Each branch goes through a number of versions, e.g. zathras.stable.3, zathras.testing.7.

Other developers do the same: they have two branches: stable and testing. Suppose there is version called Tachikoma.stable.7.

Now we can formulate a condition: if there are xxx, yyy, i and j such that: xxx.stable.i disagrees with yyy.stable.j, and there is a possibility that user A uses xxx.stable.i while user B uses yyy.stable.j, it is a very serious fuck up.

Note that this means that if your old version, let's call it zathras.stable.2 disagrees with some new version released by Tachikoma, let's say Tachikoma.stable.7, it is a fuck up.

How is it even possible to do this without fuck ups?

You should tie it to block numbers. Let's say zathras.stable.3 works only until block 275000, after that it tells user that he should upgrade. This means that if you want to update rules in a stable branch, new rules should be applicable since block 275001.

Of course, you don't need to be that rigorous with testing branches, but at some point you'll need to produce stable versions.

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

Sorry, but you have no idea what "hard fork" means.

Look, I'm not nitpicking, I'm trying to help. There is a huge disconnect between level of rigorousness applied by Bitcoin core dev team and Mastercoin developers.

It looks like you do not understand the consequences.

Hey Killerstorm,

Thanks for your response, greatly appreciated.  I don't consider any feedback nitpicking and am always happy to hear all views Smiley

Rather than get into a debate on semantics regarding the meaning of "hard fork" I'd be interested to hear what others think about our development approach also.  For clarity though we don't have anything 'stable' - not even close.  Rapid prototyping (RAD) is the order of the day for now.

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.

Thanks!


Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 28 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!