NXT :: descendant of Bitcoin - Updated Information - page 1584.

marcus03

full member

Activity: 224

Merit: 100

Quote from: marcus03 on January 10, 2014, 02:54:40 PM

Quote from: marcus03 on January 05, 2014, 05:02:54 PM

Quote from: marcus03 on January 03, 2014, 03:11:33 PM

Since I need to take a day off of programming, here's the first version of my, yet unnamed, NXT client for Windows.
...

I'm releasing version 1.1. of my Windows NXT client (still no personal account management, NTX transfer options in it or anything that needs your account secret).

Version 1.2. of my Windows NXT client "NXT Solaris" is available: ...

Here is version 1.3 of my Windows NXT client "NXT Solaris".

Download
NXTSolaris-v1.3.zip (39.2 MB) – Download here

SHA256 checksum for NXTSolaris-v1.3.zip: 95B5139E599EFD404E6D317D0A366483E6E30198CE8C3CA14B8CAAE6D3B63C92

SHA256 checksum for nxtapi.dll (v1.3): 2734F788249EF7A1E5836102D66FD97521B0F46E04E95508ABEDDF437468B46D
SHA256 checksum for NXTSolaris.exe (v1.3): 283B18858920FA67BFE8E8CC6EAE5692BE342290FC12D6EA5EF341A67789B288

For more screenshots, please visit: http://nxtsolaris.wordpress.com/

Installation
Simply unzip the archive and run the NXTSolaris.exe file.

If you tried a previous version, simply overwrite all existing files, with the files in the v1.3 zip archive.

Changes for v1.3
-Moved all http API calls and the secret input dialog to a separate open-source dll (source is included together with a a build.bat file)
-Added “Send NXT” function
-Added “Send message” function
-Added “Assign alias” function
-Added alias and message list in personal account management
-Added address book
-Got rid of the ugly button toolbars and switched to a ribbon interface
-Now showing Date/Time of last transaction in the personal account management (also defines the sort order)
-Showing cumulativeDifficulty and totalEffectiveBalance on the status page
-Showing chance to forge in personal account management
-Attachment columns in transactions lists now show decoded plain text messages as a hint
-Bug fix: Public keys in the account lists could get lost
-Fixed logging
-A bunch of other small GUI changes

My TODO list for the next versions in no special order
-Create “new account” function in the API dll (including secure password generator)
-Market data charts
-Show value of NXT in fiat currencies
-Offer a simple and advanced GUI, with the simple GUI targeted at new and casual users
-Orphan cleanup
-Bundle NRS with NXT Solaris (or maybe switch to another implementation if it is available)
-Arbitrary message encryption
-Reed Solomon addresses
-GUI and data retrieval optimization
-Asset exchange support

Donations
I hope you like my client and I’d be extremely happy to see some donations for the future of this project!

NXT: 1758531264253431177

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: pinarello on January 17, 2014, 11:32:16 AM

CfB,

result of the rewards vote for sites and social media.

would you be so kind to pay the people that won, thank you.

S3MKi    82 (31.3%)
allwelder    57 (21.8%)
Mac Red    42 (16%)
yulkisa    39 (14.9%)
Damelon    13 (5%)
Passion_ltc    11 (4.2%)
Coinonaer    8 (3.1%)
apenzl    3 (1.1%)
Mises_77    3 (1.1%)
pablito89    2 (0.8%)
^[GS]^    2 (0.8%)

1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000

Any chance that u have their accounts ready?

salsacz

hero member

Activity: 490

Merit: 504

Quote from: Come-from-Beyond on January 17, 2014, 11:16:26 AM

Quote from: ImmortAlex on January 17, 2014, 10:58:30 AM

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.

the paper is only the source of the information (will be with all citations) for the infographics and for the video

sherpico77

member

Activity: 72

Merit: 11

Quote from: DeadlyEskimo on January 17, 2014, 06:38:52 AM

Everyone should Vote here:

https://bitcointalksearch.org/topic/poll-which-coin-do-you-want-to-see-added-to-httpcryptokopeneu-417125

NXT is on top - DO IT!

Done

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: superresistant on January 17, 2014, 11:30:54 AM

Quote from: jl777 on January 17, 2014, 10:59:16 AM

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

I think Alias says planB can be reasonably quickly actually implemented using DAC and XCP, but I have no idea how it is done. I am only good for coming up with crazy ideas that sometimes aren't so crazy

James

ImmortAlex

hero member

Activity: 784

Merit: 501

Quote from: Come-from-Beyond on January 17, 2014, 11:16:26 AM

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

Do we need to spend some coins to Marvel? Childen like new superheroes! Why do we always talk about promoting among Joe Sixpack? What about his son Jimmy The Chav? Cheesy

pinarello

full member

Activity: 266

Merit: 100

NXT is the future

CfB,

result of the rewards vote for sites and social media.

would you be so kind to pay the people that won, thank you.

S3MKi    82 (31.3%)
allwelder    57 (21.8%)
Mac Red    42 (16%)
yulkisa    39 (14.9%)
Damelon    13 (5%)
Passion_ltc    11 (4.2%)
Coinonaer    8 (3.1%)
apenzl    3 (1.1%)
Mises_77    3 (1.1%)
pablito89    2 (0.8%)
^[GS]^    2 (0.8%)

1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000

superresistant

legendary

Activity: 2156

Merit: 1131

Quote from: jl777 on January 17, 2014, 10:59:16 AM

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

Anon136

legendary

Activity: 1722

Merit: 1217

Quote from: Come-from-Beyond on January 17, 2014, 11:25:23 AM

Quote from: NxtChoice on January 17, 2014, 11:23:33 AM

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.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Alias on January 17, 2014, 11:18:12 AM

Quote from: jl777 on January 17, 2014, 10:59:16 AM

[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

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: NxtChoice on January 17, 2014, 11:23:33 AM

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?

Anon136

legendary

Activity: 1722

Merit: 1217

Quote from: ImmortAlex on January 17, 2014, 11:22:18 AM

Quote from: Anon136 on January 17, 2014, 11:11:15 AM

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

smartwart

full member

Activity: 171

Merit: 100

Quote from: instacalm on January 17, 2014, 11:02:16 AM

Quote from: smartwart on January 17, 2014, 10:58:36 AM

Quote from: Alias on January 17, 2014, 10:29:32 AM

He has already said the following:

Quote

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

https://bitcointalksearch.org/topic/m.4563665

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?

opticalcarrier

full member

Activity: 238

Merit: 100

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?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: instacalm on January 17, 2014, 11:17:56 AM

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.

NxtChoice

full member

Activity: 238

Merit: 100

Quote from: Come-from-Beyond on January 17, 2014, 11:13:16 AM

Quote from: NxtChoice on January 17, 2014, 10:45:37 AM

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.

ImmortAlex

hero member

Activity: 784

Merit: 501

Quote from: Anon136 on January 17, 2014, 11:11:15 AM

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.

Alias

full member

Activity: 127

Merit: 100

Money be green

Quote from: jl777 on January 17, 2014, 11:17:19 AM

Quote from: Alias on January 17, 2014, 11:04:29 AM

Quote from: xyzzyx on January 17, 2014, 10:54:32 AM

Quote from: Alias on January 17, 2014, 10:37:25 AM

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.

Alias

full member

Activity: 127

Merit: 100

Money be green

Quote from: jl777 on January 17, 2014, 10:59:16 AM

[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?

instacalm

hero member

Activity: 798

Merit: 500

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

Topic: NXT :: descendant of Bitcoin - Updated Information - page 1584. (Read 2761647 times)