NXT :: descendant of Bitcoin - Updated Information

[Come-from-Beyond]

Doh!

   "hash":   "a680aec728f77f26012a8e998a955cd11efbe988e777e038c9e47fccee94f613",

"GUID" is actually called "hash", I kept waiting for a "GUID" field...

Can you explain how the malleable txid can be trusted to retrieve the proper hash? Does this I assume I wait for 10 confirmations? Do I have to make sure a specific txid is matched with hash, or can I just throw away the txid and index off of hash. Is there a getTransaction I can call by passing in hash?

James

Use only hash, Jean-Luc added ability to get transactions by hash, iirc.

[chanc3r]

@jl777
if you need cash for servers, come knock on InfComs door.....

@Opticalcarrier;
I'm quite happy for u to submit a request for funding for SSL on forum and wiki servers.

+1

[EvilDave]

Lots cut....

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

Can I summarise the SSL situation as:

 No SSL on nodes. Not needed.

 SSL on forums/wiki may be useful, if only as security theater.

 Wesleys client must have SSL in order to function securely. http://nxtra.org/nxt-client/

Correct me if i'm wrong.

[Touque]

If you want to subsidize and compensate the people who run the servers and service, why don't subsidize with NXT or charge NXT for using your service? Who will pay for it? Will you use the NXT community fund to subsidize the service in the beginning?

I dont have that much NXT myself to be able to afford any significant NXT subsidy.

I could charge NXT, but the whole issue has been that small stakeholders cant forge any meaningful amount of NXT, while everyone can mine enough nodecoins for the fees for my servers. I figured it was better to make multigateway services affordable for everyone.

I seem to have been fired from managing the NXTcash project and as trustee of NXTcommunityfund, but not sure. Nobody seems to tell me the important stuff.

I was planning on continuing to pay for my servers as long as I could afford to. Making it selfsufficient by charging fees would create stability, which seems like a good tradeoff.

James

You can apply for financial support from the infras committee which is set up for the projects as yours. http://107.170.117.237/index.php

[EvilDave]

Here's a reminder: Don't forget your target audience, the average crypto investor.

This is an assumption.

One that I don't share, by the way.

Umm.. OK.

Obviously this project is for the "elite" of the tech world.

Thanks for reminding why I don't even bother to come here anymore.

Disappointing to see such a great project / idea turn into such an elitist mentality.

What the buggery....?

Elitist ?

Just because we're trying to build something with a little bit more frigging ambition than mine, pump, dump, repeat ?

It's been said before, but NXT is for everyone.
If L+F (or anyone else) wants to concentrate on NXT as a first gen crypto, then he's got all the room in the world to do so.
2nd gen features do not explicitly exclude all of the simpler first gen stuff.
Maybe L+F could set up a first gen workgroup/posse to concentrate on the promotion and use of NXT in the first gen space........?

[jl777]

@jean-luc
Can I rely on a "comment" field for transferAsset? Without that correlating multigateway deposit with corresponding asset transfer will have to use other means. At best, it will delay proper crediting. It sure would make it a lot easier and quicker for me if I could assume a comment could be optionally added to transferAsset

James

[wesleyh]

Can I summarise the SSL situation as:

 No SSL on nodes. Not needed.

 SSL on forums/wiki may be useful, if only as security theater.

 Wesleys client must have SSL in order to function securely. http://nxtra.org/nxt-client/

Correct me if i'm wrong.

My client doesn't need SSL to function securely (No passwords are sent to the server). Jean-luc talks about privacy. Not sure what he means by that though. However if you want to forge, the API requires that you send your password so that does needs SSL.

SSL on forums/wiki is needed though, since otherwise pw's are sent in the clear.

[Jean-Luc]

@jean-luc
Can I rely on a "comment" field for transferAsset? Without that correlating multigateway deposit with corresponding asset transfer will have to use other means. At best, it will delay proper crediting. It sure would make it a lot easier and quicker for me if I could assume a comment could be optionally added to transferAsset

James

Yes, I will add that to asset transfer, it could have other legitimate uses, and asset transfers would not be that frequent compared to ask/bid orders to worry about bloat.

[Emule]

Here's a reminder: Don't forget your target audience, the average crypto investor.

This is an assumption.

One that I don't share, by the way.

Umm.. OK.

Obviously this project is for the "elite" of the tech world.

Thanks for reminding why I don't even bother to come here anymore.

Disappointing to see such a great project / idea turn into such an elitist mentality.

What the buggery....?

Elitist ?

Just because we're trying to build something with a little bit more frigging ambition than mine, pump, dump, repeat ?

It's been said before, but NXT is for everyone.
If L+F (or anyone else) wants to concentrate on NXT as a first gen crypto, then he's got all the room in the world to do so.
2nd gen features do not explicitly exclude all of the simpler first gen stuff.
Maybe L+F could set up a first gen workgroup/posse to concentrate on the promotion and use of NXT in the first gen space........?

nxt is for geeks, not for average joe.

at least with pump and dump something is happening to the price and even small stakeholders can have some profit. with nxt only early stakeholders founders can profit.

[jl777]

Doh!

   "hash":   "a680aec728f77f26012a8e998a955cd11efbe988e777e038c9e47fccee94f613",

"GUID" is actually called "hash", I kept waiting for a "GUID" field...

Can you explain how the malleable txid can be trusted to retrieve the proper hash? Does this I assume I wait for 10 confirmations? Do I have to make sure a specific txid is matched with hash, or can I just throw away the txid and index off of hash. Is there a getTransaction I can call by passing in hash?

James

Use only hash, Jean-Luc added ability to get transactions by hash, iirc.

However, https://bitbucket.org/JeanLucPicard/nxt/src/7e92adc64272dd7a095e0f36f286b13ad2541826/src/java/nxt/http/GetBlock.java?at=master

only seems to support getting txids from a block, not a list of hashes...

How can I get a trusted list of transaction hashes to know what to lookup?

Scanning each block for all transactions to find asset transfers is the only way I know of to get a list of asset transfers for an asset (or acct). For buy/sells, getTrades gets the list, but again I think it is a list of txids...

To go to an unmalleable hash based tx wouldnt there need to be a method to get all the transactions without ever using txid?

James

[jl777]

@jean-luc
Can I rely on a "comment" field for transferAsset? Without that correlating multigateway deposit with corresponding asset transfer will have to use other means. At best, it will delay proper crediting. It sure would make it a lot easier and quicker for me if I could assume a comment could be optionally added to transferAsset

James

Yes, I will add that to asset transfer, it could have other legitimate uses, and asset transfers would not be that frequent compared to ask/bid orders to worry about bloat.

Thanks!
Where can I find latest API? wiki is totally out of date, I have no idea how to lookup transaction based on hash

[Come-from-Beyond]

However, https://bitbucket.org/JeanLucPicard/nxt/src/7e92adc64272dd7a095e0f36f286b13ad2541826/src/java/nxt/http/GetBlock.java?at=master

only seems to support getting txids from a block, not a list of hashes...

How can I get a trusted list of transaction hashes to know what to lookup?

Scanning each block for all transactions to find asset transfers is the only way I know of to get a list of asset transfers for an asset (or acct). For buy/sells, getTrades gets the list, but again I think it is a list of txids...

To go to an unmalleable hash based tx wouldnt there need to be a method to get all the transactions without ever using txid?

James

Do u have transaction bytes? If yes, then replace "signature" with zeros and calc SHA256, this will be hash.

[opticalcarrier]

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

But how long do we expect before we change from TCP to UDP?  Once that happens we cannot use SSL at all.  So if its soon, do we just want to do things in the clear until then, since its going to be in the clear anyways?  Or perhaps you want to revisit going to UDP in the first place since you cannot get security that way?

[Jean-Luc]

My client doesn't need SSL to function securely (No passwords are sent to the server). Jean-luc talks about privacy. Not sure what he means by that though. However if you want to forge, the API requires that you send your password so that does needs SSL.

SSL on forums/wiki is needed though, since otherwise pw's are sent in the clear.

When a node receives a transaction from another node, it does not know where this transaction originated from, it could have been forwarded from yet another node. But when your client uses broadcastTransaction to send a transaction to a node, anyone monitoring the clear traffic between the client and the node will know that the transaction originated from that client IP. If you use SSL, at least you are protecting the client privacy from the ISP and anyone who can spy along the route. The public node operator still gets to know that your IP signed and sent the transaction.

For forums and wiki SSL is indeed essential, unless we all start signing each of our posts and PMs with GPG.

[jl777]

However, https://bitbucket.org/JeanLucPicard/nxt/src/7e92adc64272dd7a095e0f36f286b13ad2541826/src/java/nxt/http/GetBlock.java?at=master

only seems to support getting txids from a block, not a list of hashes...

How can I get a trusted list of transaction hashes to know what to lookup?

Scanning each block for all transactions to find asset transfers is the only way I know of to get a list of asset transfers for an asset (or acct). For buy/sells, getTrades gets the list, but again I think it is a list of txids...

To go to an unmalleable hash based tx wouldnt there need to be a method to get all the transactions without ever using txid?

James

Do u have transaction bytes? If yes, then replace "signature" with zeros and calc SHA256, this will be hash.

Are you saying that to avoid malleability, I need to do a getTransactionbytes, calc SHA256 and compare that with the "hash" of getTransaction and then reject any that doesnt match?

Maybe I just wait for 10 confirmations. Seems like it is too much work otherwise. At 10 confirmations, you said I can trust txid

James

[Come-from-Beyond]

But how long do we expect before we change from TCP to UDP?  Once that happens we cannot use SSL at all.  So if its soon, do we just want to do things in the clear until then, since its going to be in the clear anyways?

We'll be using both (TCP and UDP) for a long time.

[Come-from-Beyond]

Are you saying that to avoid malleability, I need to do a getTransactionbytes, calc SHA256 and compare that with the "hash" of getTransaction and then reject any that doesnt match?

Maybe I just wait for 10 confirmations. Seems like it is too much work otherwise. At 10 confirmations, you said I can trust txid

James

ZERO signature before SHA256. And btw, u still should wait for confirmations to avoid double-spending.

[Jean-Luc]

But how long do we expect before we change from TCP to UDP?  Once that happens we cannot use SSL at all.  So if its soon, do we just want to do things in the clear until then, since its going to be in the clear anyways?

It is certainly not soon. Besides, it is my understanding that UDP will only be used for sending transactions for fast processing directly to the node that is known to be the one to generate the next block. So at least the TF should be completely implemented before that. And the existing http API will continue to be used, necessarily over TCP.

[opticalcarrier]

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

But how long do we expect before we change from TCP to UDP?  Once that happens we cannot use SSL at all.  So if its soon, do we just want to do things in the clear until then, since its going to be in the clear anyways?  Or perhaps you want to revisit going to UDP in the first place since you cannot get security that way?

wait, nevermind, I think I get it.  the UDP migration will only be for p2p, right?  The API will still reside on TCP and thus can use SSL?

[EvilDave]

Cut...

What the buggery....?

Elitist ?

Just because we're trying to build something with a little bit more frigging ambition than mine, pump, dump, repeat ?

It's been said before, but NXT is for everyone.
If L+F (or anyone else) wants to concentrate on NXT as a first gen crypto, then he's got all the room in the world to do so.
2nd gen features do not explicitly exclude all of the simpler first gen stuff.
Maybe L+F could set up a first gen workgroup/posse to concentrate on the promotion and use of NXT in the first gen space........?

nxt is for geeks, not for average joe.

at least with pump and dump something is happening to the price and even small stakeholders can have some profit. with nxt only early stakeholders founders can profit.

There are approximately 187 crypto-currencies on coinmarketcap.com right now, most of these can be pumped and dumped, and I'm sure that absolutely none of them have any sort of early stakeholder issue.

So why are u hanging around here whining like a little bitch, Elmo?