^[GS]^
Member
Offline
Activity: 112
Merit: 10
|
|
February 10, 2014, 12:57:43 PM |
|
The idea was to prevent hacking and emptyings. Is almost impossible to make a error sending by placing the phrase and all. My next idea to prevent hacking and emptyings consists to create a second key 16-32 characters. That would register like the ALIAS. Key is not used to unlock the account, only to send! The key can be changed.
|
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 10, 2014, 01:01:47 PM |
|
Nxt exchanges shouldn't rely on transaction ids though. Coz ids can be changed in a way similar to Bitcoin.
So - there we have it from CfB - Nxt has THE SAME problem as Bitcoin. Can you please stop the stupid tweets now as I can see CfB's statement being used as the "payback".
|
|
|
|
abctc
Legendary
Offline
Activity: 1792
Merit: 1038
|
|
February 10, 2014, 01:02:36 PM |
|
|
██████████████████████████████████████████████████ ████████████████████████████████████████████████████ ██████████████████████████████████████████████████████ ████████████████████████████████████████████████████████ ████████████████████████████████████████████████████████ ████████████████████████████████████████████████████████████████████ ████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ████████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████████ ████████████████████████████████████████████████████████████████████ | , the Next platform. Magis quam Moneta (More than a Coin) |
|
|
|
BitcoinForumator
Legendary
Offline
Activity: 1120
Merit: 1000
|
|
February 10, 2014, 01:04:15 PM |
|
Nxt exchanges shouldn't rely on transaction ids though. Coz ids can be changed in a way similar to Bitcoin.
So - there we have it from CfB - Nxt has THE SAME problem as Bitcoin. Can you please stop the stupid tweets now as I can see CfB's statement being used as the "payback". Delete this asap Edit: i will delete it to
|
|
|
|
jkoil
|
|
February 10, 2014, 01:06:47 PM |
|
if you're asking if negative input is legal, yes it is. To simplify it, it's similar to how modulo operates in C. If you do: int x = (1-3) % 5; // -2 % 5
you'll get "-2" as a result, but what you're actually interested in is: int x = (1-3 + group_order) % 5; // (-2 + 5) % 5 = 3 % 5 == 5
group_order == 5, and you'll get 3 as a result... Yes, I know. So, the problem is that -2 or 3 is processed further and we are not certain if -2 behaves differently than 3 does. That is certainly a problem. EDIT: we are not certain if the 3 resulting from a -2 is process the same way as we would give it another try. "-2" is passed as input to verify() which was expecting to see "3" not "-2"... But it is not sure, if -2 in form as a 3 would result in the same outcome as it would be a 'real' 3 from the beginning. In math -2 mod 5 equals 3. Is that the result, which is wanted? ... in that case C implementation is wrong there and should not use % with negative numbers. (change to positive by adding 5) I think that's not the point here. Consider this: b = f(a)
c = g(b)
d = h(a, c)
Let's assume c results in -2 with a certain b. Even if c=-2 and c=3 are interchangeable mathematically, h might not work as expected as the pair (a, c) belong together. So, it could be the case that h(a, -2) != h(a, 3) for the very same a. This must be avoided at any cost. yes ... and no No; I didn't mean that c=-2 and c=3 are interchangeable. The results and consequences are likely different, possibly in "many" cases, where the c will be used (in h(a,c) as you stated). Yes; as you said "this must be avoided at any cost." I agree, when not knowing the background of the original implementation (has it been assumed that no negative input or something else...)
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 10, 2014, 01:08:55 PM |
|
Delete this asap Just as those who "couldn't resist" trying to "score points" from the FUD - I can't resist keeping the "told you so".
|
|
|
|
BitcoinForumator
Legendary
Offline
Activity: 1120
Merit: 1000
|
|
February 10, 2014, 01:11:29 PM |
|
Delete this asap Just as those who "couldn't resist" trying to "score points" from the FUD - I can't resist keeping the "told you so". I know But many/most? of us actually put a lot of weight to your words.
|
|
|
|
wesleyh
|
|
February 10, 2014, 01:11:50 PM |
|
So why does nxt have this problem too? Is this something inherent to crypto currencies?
Can it be fixed? Will it be fixed? What should exchanges rely on instead of transaction Ids / transaction bytes?
|
|
|
|
bitcoinpaul
|
|
February 10, 2014, 01:13:07 PM |
|
The idea was to prevent hacking and emptyings. Is almost impossible to make a error sending by placing the phrase and all. My next idea to prevent hacking and emptyings consists to create a second key 16-32 characters. That would register like the ALIAS. Key is not used to unlock the account, only to send! The key can be changed. BCNext implements Account Control. Let's wait for that...
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 10, 2014, 01:16:23 PM |
|
So why does nxt have this problem too? Is this something inherent to crypto currencies?
Can it be fixed? Will it be fixed? What should exchanges rely on instead of transaction Ids / transaction bytes?
It is due to the way a tx is constructed and hashed - if the signature(s) do not include every byte of the transaction then it will always be possible to modify the tx and if the hash is of the entire tx (not just the signed part(s)) then there is not much you can do about it apart from: Don't rely upon the tx hash (something Mt. Gox should never have been doing in the first place). Nxt does actually make things simpler in that you can just use Account #s (you don't have to deal with UTXOs). An exchange should only display a txid *after* the tx has been confirmed (until then it should just be displayed as "unconfirmed" with no hash at all) and even then the txid should only be handled as "descriptive" data (i.e. not indexed for any important purpose).
|
|
|
|
pandaisftw
|
|
February 10, 2014, 01:17:37 PM |
|
So why does nxt have this problem too? Is this something inherent to crypto currencies?
Can it be fixed? Will it be fixed? What should exchanges rely on instead of transaction Ids / transaction bytes?
Only thing I can think of off the top of my head is individualized accounts, so you can constantly poll getGauranteedBalance on them. Question: If what parts of the transactions can be faked? The sender ID? All of it?
|
NXT: 13095091276527367030
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
February 10, 2014, 01:18:23 PM |
|
So why does nxt have this problem too? Is this something inherent to crypto currencies?
Can it be fixed? Will it be fixed? What should exchanges rely on instead of transaction Ids / transaction bytes?
It's a problem only for exchanges that rely solely on transaction id. It doesn't need to be fixed. An exchange is supposed to pay attention to timestamp and other parameters of a transaction.
|
|
|
|
^[GS]^
Member
Offline
Activity: 112
Merit: 10
|
|
February 10, 2014, 01:23:52 PM |
|
The idea was to prevent hacking and emptyings. Is almost impossible to make a error sending by placing the phrase and all. My next idea to prevent hacking and emptyings consists to create a second key 16-32 characters. That would register like the ALIAS. Key is not used to unlock the account, only to send! The key can be changed. BCNext implements Account Control. Let's wait for that... ahhh! I did not know! expect expect!
|
|
|
|
gimre
Legendary
Offline
Activity: 866
Merit: 1002
|
|
February 10, 2014, 01:27:31 PM |
|
I think that's not the point here. Consider this: b = f(a)
c = g(b)
d = h(a, c)
Let's assume c results in -2 with a certain b. Even if c=-2 and c=3 are interchangeable mathematically, h might not work as expected as the pair (a, c) belong together. So, it could be the case that h(a, -2) != h(a, 3) for the very same a. This must be avoided at any cost. That IS the case, as h == verify, verify WORKS (validates) on "3" (and it SHOULD work on "3") and doesn't work on "-2", (that's why you can see those "Generated incorrect block messages")
|
|
|
|
salsacz
|
|
February 10, 2014, 01:36:36 PM |
|
important people from Berlin conf are responding on my invitation and they are very excited about Nxt
|
|
|
|
Bitventurer
|
|
February 10, 2014, 01:41:35 PM |
|
important people from Berlin conf are responding on my invitation and they are very excited about Nxt let's decide how much coins we will tip away...infecting people with NXT from our smartphones...
|
SP8DE - The Game of Chance. Changed.
|
|
|
allwelder
Legendary
Offline
Activity: 1512
Merit: 1004
|
|
February 10, 2014, 01:43:28 PM |
|
tell you DGEX to send and receive your deposits in 10 minutes. lol
I don't know what Dgex problems are but I can use bter to sell and buy Nxt within minutes. This is DGex problem, not Nxt. Would you buy online clips (porn or not) with Nxt if you get the download link AFTER 24 hours? That will make Nxt useless. Even bitcoin with 10 minute for one confirmation is faster. I will accept Nxt as a merchant with even one confirmation (1 minute), but I won't accept Nxt if transactions are reversible for 24 hours. I would rather then find a better currency. no body said the transaction is reversible.
|
|
|
|
lovebit
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 10, 2014, 01:45:40 PM |
|
I heard on Lets Talk Bitcoin a few nights ago that the Zerocoin protocol is being developed for NXT. Does this mean that NXT is developing a Zercoin-like protocol or have the Zerocoin developers decided to build on top of NXT? Are the developers working together?
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
February 10, 2014, 01:46:25 PM |
|
important people from Berlin conf are responding on my invitation and they are very excited about Nxt Do u mean Angela Merkel?
|
|
|
|
|