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

opticalcarrier

full member

Activity: 238

Merit: 100

Quote from: Eadeqa on March 23, 2014, 04:01:45 PM

Quote from: wesleyh on March 23, 2014, 03:38:27 PM

Quote from: EvilDave on March 23, 2014, 03:26:10 PM

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 is needed to ensure that javascript client is not manipulated during transmission

depending on the client and how "light" it is, this may/not be the case (assuming a not-so-light-client does verify the returned bytes before signing). But it always IS the case that its possible to tie an account ID to IP address if not using SSL. But the infrastructure committee deems tor to be the solution. Im about to upgrade all my VPSs to 0.8.12 and will remove SSL. So everyone prepare for the howls of "ahhhh, now we dont have to use the java client, but we have to figure out TOR???"

Wesley, can your client be configured to also handle its own DNS, and route DNS requests through tor or does it hand DNS off to the OS? if the latter then this setup will leak DNS even if tor is used.

mikesbmw

sr. member

Activity: 338

Merit: 250

Quote from: ?? on ??

Quote from: EvilDave on March 23, 2014, 04:15:31 PM

Quote from: ?? on ??

Quote from: Emule on March 23, 2014, 04:00:07 PM

cos i feel so loved here Grin

hey pinarello, alles goed met je ?

Gotverdomme...een stealth-Nederlander!

godverdomme* Hè jakkiebah*

FIFY

mr_random

legendary

Activity: 1344

Merit: 1001

Quote from: Emule on March 23, 2014, 03:39:45 PM

nxt is for geeks, not for average joe.

What do you think Bitcoin started off as? Roll Eyes

lyynx

sr. member

Activity: 380

Merit: 275

Quote from: ?? on ??

What is he talking about??

http://letstalkbitcoin.com/ltb94-privacy-and-the-arts/#.Uy8-KfmSwrU

56:50

Just bumping this, we cannot allow disinformation to run unchecked.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Jean-Luc on March 23, 2014, 04:09:57 PM

Quote from: jl777 on March 23, 2014, 03:41:21 PM

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?

http://localhost:7876/test for a listing of all available APIs and their parameters.

getAccountTransactions supports filtering by type and subtype, you can get asset transfer transactions for a given account. But this still returns transaction id's only, not the full transaction json. The API needs improvement.

Are you sure you need to use the hash and not just the transaction id? IDs are still guaranteed to be unique and continue to be used as the unique identifier internally. Hashes are used to make sure no new transactions are accepted that are duplicates (in all fields other than the signature) of an existing transaction even though they may have a different id.

Fantastic page! I missed it.

I am not sure of anything about this hash stuff. It sounds like I can continue to index everything by txid, but put in a check to make sure that there is no other txid with the same hash?!

Sorry if I am asking silly stuff. It sounded like people could fiddle with txid and that I couldnt trust txids to be valid. From what you are saying, it sounds like this is not the case. The attack the hash is addressing is people submitting the same transaction and making it look like a totally new one. So if I make sure that there is no conflict at the transaction hash level, we will know this didnt happen.

If there is a collision of the transaction hash, which one is the imposter? I guess safer to invalidate both?

James

EvilDave

hero member

Activity: 854

Merit: 1001

Quote from: ?? on ??

Quote from: Emule on March 23, 2014, 04:00:07 PM

cos i feel so loved here Grin

hey pinarello, alles goed met je ?

Gotverdomme...een stealth-Nederlander!

Jean-Luc

sr. member

Activity: 392

Merit: 250

Quote from: jl777 on March 23, 2014, 03:41:21 PM

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?

http://localhost:7876/test for a listing of all available APIs and their parameters.

getAccountTransactions supports filtering by type and subtype, you can get asset transfer transactions for a given account. But this still returns transaction id's only, not the full transaction json. The API needs improvement.

Are you sure you need to use the hash and not just the transaction id? IDs are still guaranteed to be unique and continue to be used as the unique identifier internally. Hashes are used to make sure no new transactions are accepted that are duplicates (in all fields other than the signature) of an existing transaction even though they may have a different id.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Come-from-Beyond on March 23, 2014, 03:52:56 PM

Quote from: jl777 on March 23, 2014, 03:49:23 PM

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.

Wait, so I HAVE to do all this complicated stuff AND wait for 10 confirmations? It seems like some GUIDs could get lost if all the querying is done via txid.

James

P.S. Any URL for good SHA256 C source code?

chanc3r

sr. member

Activity: 952

Merit: 253

Quote from: Emule on March 23, 2014, 04:00:07 PM

cos i feel so loved here Grin

Of course you do sweetie http://www.youtube.com/watch?v=N_gdN94iMQk

Do I smell the merest hint of desperation in your posts these days besides the obvious eau-de-bull...

martismartis

legendary

Activity: 1162

Merit: 1005

I see only two accounts are forging on the testnet, one of them is me

Or I am on testnet fork?

Check:
94612 3/23/2014 22:59:59 0 0 0 5728597073699734894 0 B 3703071 %

Eadeqa

hero member

Activity: 644

Merit: 500

Quote from: wesleyh on March 23, 2014, 03:38:27 PM

Quote from: EvilDave on March 23, 2014, 03:26:10 PM

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 is needed to ensure that javascript client is not manipulated during transmission

EvilDave

hero member

Activity: 854

Merit: 1001

aww...what a sweety Elmo...*tickles behind ears*

Emule

full member

Activity: 168

Merit: 100

Quote from: EvilDave on March 23, 2014, 03:57:19 PM

Quote from: Emule on March 23, 2014, 03:39:45 PM

Quote from: EvilDave on March 23, 2014, 03:32:10 PM

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?

cos i feel so loved here Grin

EvilDave

hero member

Activity: 854

Merit: 1001

Quote from: Emule on March 23, 2014, 03:39:45 PM

Quote from: EvilDave on March 23, 2014, 03:32:10 PM

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?

opticalcarrier

full member

Activity: 238

Merit: 100

Quote from: opticalcarrier on March 23, 2014, 03:48:13 PM

Quote from: Jean-Luc on March 23, 2014, 03:14:07 PM

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?

Jean-Luc

sr. member

Activity: 392

Merit: 250

Quote from: opticalcarrier on March 23, 2014, 03:48:13 PM

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.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: jl777 on March 23, 2014, 03:49:23 PM

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.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: opticalcarrier on March 23, 2014, 03:48:13 PM

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.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Come-from-Beyond on March 23, 2014, 03:44:59 PM

Quote from: jl777 on March 23, 2014, 03:41:21 PM

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

Jean-Luc

sr. member

Activity: 392

Merit: 250

Quote from: wesleyh on March 23, 2014, 03:38:27 PM

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.

Topic: NXT :: descendant of Bitcoin - Updated Information - page 170. (Read 2761645 times)