NXT :: descendant of Bitcoin - Updated Information

[jl777]

Last night a few developers and myself where brainstorming on the concepts of implementing Nxt into e-commerce applications and one use does not seem to be possible.

I do not believe this question has been asked yet, but since Nxt is to be used as a currency, I think there is one use we have yet to touch upon.

Recurring payments? Since Nxt will not only be used for purchasing, but I'm sure for services, many of which will be subscription based, how, if it all, will this be possible? Will this be a function of the client? Is this built into the framework already?

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

[chanc3r]

did I somehow forge an empty block or are there unlucky blocks and I've been unlucky 3 times in a row?

Right. There are still many empty blocks on network.

So what causes the empty blocks and will there always be so many?
Because then the description of the likelihood to forge a block i'm sure is correct, but the likely hood of a reward from that is 25%  
based on my current experience.

[Anon136]

did I somehow forge an empty block or are there unlucky blocks and I've been unlucky 3 times in a row?

Right. There are still many empty blocks on network.

So what causes the empty blocks and will there always be so many?
Because then the description of the likelihood to forge a block i'm sure is correct, but the likely hood of a reward from that is 25%  
based on my current experience.

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.

[starik69]

So what causes the empty blocks and will there always be so many?

Empty blocks are blocks without transactions. More transactions - less empty blocks.

[Come-from-Beyond]

1) I remember (If I am right) CfB once said he owns 3 Mil Nxt about two weeks ago, and today or yesterday he said he owns 5 Mil Nxt. As we know, CfB sold a little Nxt every cheap weeks ago, but now he owns more. CfB, did you buy in recently?

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

[Come-from-Beyond]

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

Aye, we don't need too many myths. The Bible 2.0 shouldn't be very thick, leave some room for picture, kids don't like to read walls of text.

[jl777]

Could the trust in a particular NXT gateway be amplified/compounded using multisig or something? So instead of 100 different BTC/NXT gateways, have 1 gateway with 100 backers? I.e. decentralise the assets.

Tie PoS forging power to trust metric.

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".

Ripple has what they call a bitcoin bridge. If someone could implement the equivalent functionality as a reference, then all participating Asset issuers could support the bridge function. This allows someone with a BTC colored coin to send real BTC to any actual bitcoin address. It is not a well known, but super useful function in ripple.

How we can enforce that each and every issuer honors the bitcoin bridge? It devolves to the trust issue again. The "hit by a bus" scenario needs to be solved when significant funds are involved.

We can verify BTC deposits, audit against issued assets, but server outages and other unexpected things happen.

OK, here is a crazy idea. We have 6 million unclaimed NXT that is unallocated. What if the community decides that it is really important to have a trusted BTC asset? What if the community decides to create a community backed BTC asset? What if there was 6 million NXT providing collateral for BTC insurance in case of "hit by bus" scenarios?

Using automation as much as possible to reduce the chances of anything going wrong. multisig BTC accts, whatever, but then the unclaimed NXT or large stakeholder collateralizes a NXT-DIC (FDIC equivalent)? Sounds centralized and probably totally offbase, just trying to think outside the box here.

James

[instacalm]

CfB, was it Cryptsy or Vircurex who contacted you? Any updates on this already?

[Alias]

[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

Great. So if the deposit/withdrawal software is a DAC (Distributed Autonomous Community) like the Credit Unions that I have outlined here - https://nextcoin.org/index.php/topic,1890.msg18983.html#msg18983 then we have it nailed. We would have one common reserve "BTC Colored NXT" from which all other BTC asset variants can be backed. But I would go one further and do it against XCP (Counterparty Protocol) because they can already programmatically make BTC transactions as well as XCP transactions obviously. Now we have interfaced 2 decentralised exchanges.

Edit: In the first case, won't the value of each BTCa, BTCb, BTCc all track each other closely due to arbitrage anyway?

[Alias]

Could the trust in a particular NXT gateway be amplified/compounded using multisig or something? So instead of 100 different BTC/NXT gateways, have 1 gateway with 100 backers? I.e. decentralise the assets.

Tie PoS forging power to trust metric.

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".

Ripple has what they call a bitcoin bridge. If someone could implement the equivalent functionality as a reference, then all participating Asset issuers could support the bridge function. This allows someone with a BTC colored coin to send real BTC to any actual bitcoin address. It is not a well known, but super useful function in ripple.

How we can enforce that each and every issuer honors the bitcoin bridge? It devolves to the trust issue again. The "hit by a bus" scenario needs to be solved when significant funds are involved.

We can verify BTC deposits, audit against issued assets, but server outages and other unexpected things happen.

OK, here is a crazy idea. We have 6 million unclaimed NXT that is unallocated. What if the community decides that it is really important to have a trusted BTC asset? What if the community decides to create a community backed BTC asset? What if there was 6 million NXT providing collateral for BTC insurance in case of "hit by bus" scenarios?

Using automation as much as possible to reduce the chances of anything going wrong. multisig BTC accts, whatever, but then the unclaimed NXT or large stakeholder collateralizes a NXT-DIC (FDIC equivalent)? Sounds centralized and probably totally offbase, just trying to think outside the box here.

James

Looks like I possibly addressed this with my previous post! Great minds.

[ImmortAlex]

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.

That's how every crypto since bitcoin work.
You need blocks at constant rate just to confirm previous transactions. Every new block add one confirmation and protect previous transactions.

[NxtChoice]

1) I remember (If I am right) CfB once said he owns 3 Mil Nxt about two weeks ago, and today or yesterday he said he owns 5 Mil Nxt. As we know, CfB sold a little Nxt every cheap weeks ago, but now he owns more. CfB, did you buy in recently?

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

Sorry, I am wrong. How about other questions? Your answer get me clear.

[Come-from-Beyond]

CfB, was it Cryptsy or Vircurex who contacted you? Any updates on this already?

Somehow I thought that was Cryptsy, but when I rechecked the letter I saw it's Vircurex (don't use them so they r twins to me). I sent info they asked, that's it.

[opticalcarrier]

this 0.5.8 client seems very stable to me, the best so far, for my VPSs and for my local forging client.  perhaps we are getting closer to the time where a large exchange will list NXT?

[smartwart]

He has already said the following:

QRK and NXT will be added once some funds are raised.

https://bitcointalk.org/index.php?topic=417125.msg4563665#msg4563665

don't understand.
I should fund an account there and hope they will add NXT?

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 also 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.

thank you for you comment!
I see it similar as you do.


But I was writing the question a little misleading... sorry for this
I was trying to ask if I understand it in the right way,
that prospective clients has to fund an account there,
and if the owner decides that the amount is large enough - he adds NXT to his portfolio?
Do I understand it right way?

[Anon136]

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.

That's how every crypto since bitcoin work.
You need blocks at constant rate just to confirm previous transactions. Every new block add one confirmation and protect previous transactions.

im just saying that it doesn't make sense for the individual to do it

[Come-from-Beyond]

How about other questions? Your answer get me clear.

Oh, too many words in other questions, I can't read all the text, u all post so much text. Could u create a list with short answers?

[jl777]

[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

Great. So if the deposit/withdrawal software is a DAC (Distributed Autonomous Community) like the Credit Unions that I have outlined here - https://nextcoin.org/index.php/topic,1890.msg18983.html#msg18983 then we have it nailed. We would have one common reserve "BTC Colored NXT" from which all other BTC asset variants can be backed. But I would go one further and do it against XCP (Counterparty Protocol) because they can already programmatically make BTC transactions as well as XCP transactions obviously. Now we have interfaced 2 decentralised exchanges.

Edit: In the first case, won't the value of each BTCa, BTCb, BTCc all track each other closely due to arbitrage anyway?

Without a trusted path to actual BTC, what would the theoretical arbitragers arbitrage against? Converting non-trusted BTC assets would require pretty steep percentages, so the prices won't be efficient at all.

There needs to be a trusted and preferably automated solution that is easy for BTC asset issuers to participate with. I am not familiar with DAC and XCP, but it sounds like you are. Is it a simple matter to implement what I have outlined?

if so, does it truly remove the need to trust each issuer and allow new BTC variant issuers to participate? Certainly if everybody simply traded the common Asset name, we avoid the fragmentation, but how exactly will it be decided what that agreed upon asset name is?

Theoretically it all seems easy, in reality, will the person that actually gets the BTC asset want to participate in any such group? Nothing prevents half a dozen people from all independently trying to become THE BTC asset within NXT. Very few things the community is unanimous on.

I would like to see trading of NXT without fees and commissions and I sure hope the person that actually gets the BTC asset is of like mind. This is very important for NXT community as we have seen what happens when we can trade without fees and when we have fees or usability issues.

James

[Anon136]

How about other questions? Your answer get me clear.

Oh, too many words in other questions, I can't read all the text, u all post so much text. Could u create a list with short answers?

could make a questions for cfb thread, force everyone to stay on topic there and only answer questions asked there. you know it if gets really out of hand.

[superresistant]

(...)
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.

Ok nice plan B. We have to explain it to everyone.