[need coffee, somehow quote of colored coin threads and BTC asset fragmentation was dropped...]
Anything is possible. For something like that to work, it would require N participants to all agree to honor each others coins at 1:1
For example, the people that end up with the asset names: "BTC", "BTC2", "BTCxyx", etc all agree that they will redeem each others BTC for actual BTC.
The only problem is if something goes wrong, eg. issuer of "BTC2" gets hit by a bus. What happens? Everyone with BTC2 redeems it at the other issuers, so now all the participants have a bunch of BTC2, but he is no more. On a small scale, it would work like a group self-insuring, but what if we are talking about 100BTC worth?
I don't think that approach will work at large scales, due to "hit by bus" scenario.
OK, so plan B.
Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.
On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.
On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.
The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.
In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.
So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.
James
I am not sure if exactly this is what needs to be applied but something similar sounds very logical. We can not just leace things in a way in which the seller can cheat the buyer.
I was thinking about implementing a system like Freelancers Milestone Payments, where everything works in their way, with the difference, that if dispute arrives, the third party is not one centralised person or node, but, 51% or at least some major part of the network.
In addition, in cases in which disput is present, the network is forced to vote and solve the dispute, as for this voting, each participant some small amount of NXT/BTC, part of the deal, which took place between the two problematic parties.
This way, as two parties know that if they can not make 51% of the people to support their side if they try to cheat (e.g. realise this is impossible), and in the same time, if they know that in cases in which they make problematic disputes (when trying to cheat), they pay penalty fees for this and at the end to not succeed to cheat, they will in the long run simply stop trying to cheat and everything will go smoothly.
If you are not faimliar with Freelancers Milestone system, this is how it works:
Party A sends money to Party B, but money are "stuck" in the middle, where no one can use them, A can not get them back and B can not receive them entirely.
Party B makes payment (online service, or sends product) to A in a similar way,then, A has receieve the product, but has already sent money and can not get them back. So A have even no interest to lie. Then A sends himself the money to B (to be more precise, finishes the milestone payment, and transfer the money stuck in the middle finally to B), or, if he decides to cheat, he says: I will not finish the milestone payment to B, he didnt send me the BTC (he lies). Then the majority of the network asks B, is this true, and B shows a BTC blockchain transaction reference, which with arbitrary message can be applied to the deal as a referal note, so he proves that he has sent exactly this amount to exacty A's address for exactly this deal. Then, the 51% (or some big enough part) of the community sends the money finally to B (only A or 51% of the comunity has the power to do this action). At the end, for A trying to cheat, he is penalized for some amount of money in the next deal he tries to make in the network, and the penalty is spread over the network as fee which can be forged, as there is a written exception that only A can not forge that fee.
What developers think about this and can it be implemented? We need to establish 100% trustfull system, current way is no working in practise.
Also please link to colored coins and what they have to do with trustfullness.
