go here and vote guys

https://bt.irlbtc.com/view/417125.0

Tie PoS forging power to trust metric.

salsacz, please correct you post or you will create one more myth - I am not a full-time developer of any Nxt appication.

[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

1. Java is one of the most popular languages (#1 if u need to create a cross-platform solution).
2. Jetty is one of the most popular webserver (used by Google in its app cloud service)
3. This is how all jar-packed applications r ran
4. This is standard place in Jetty

Looks like a good excuse to me, doesn't it?



Really? Ok, each day I study more and more nuances of English. It's not my mother tongue, sorry if sometimes I use incorrect words.

I am personally not interested at all in a site where I can only pay in Fiat using Skrill.

What NXT needs is large exchanges, Cryptsy and alikes. Cryptsy's feature of allowing to trade in USD is coming soon. DGEX was/is a good start despite all the criticism it has received over the past weeks.

What trust metric? The issuer of 1 gateway could demonstrate that he owns a large stake (POS) in the NXT system anyway.

I'm wondering how the need for trust can be removed from these gateways.

At least if there were a bunch of decentralised BTC/NXT gateways they have the same common reserve currency (NXT tokens) so they could trade between each other. This could ultimately ensure that "One BTC Coloured Coin = Another BTC Coloured Coin".

I would think this belongs to higher level.
Payments are supported. Subscription is regular payments, but there also needs to be support for adding/changing/removing subscriptions, all this is totally application specific.

wesleyh has some code that deals with payments and I would think building a subscription service on top of that would make sense

James

it is kind of silly that there are empty blocks. one would think that forgers would wait until there was atleast 1 transaction before having any reason to forge a block. but i guess thats not the way the client is written and it Isn't worth anyones time to mess with it.

I said I own 5M? U r wrong, I said I owned 5M.