Bitcoin Forum
December 15, 2024, 10:51:25 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 [2134] 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761621 times)
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
March 10, 2014, 03:11:52 PM
 #42661

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

what will happen if the user has already sent a fund to this less-than-15-chars-passphrase account but the fund has not been conformed and shown up in the balance yet? Should not allow to create a less than 35 chars pass phrase in the first place.

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

The first transaction of an account is always an incoming transaction and the secret for the recipient account is not needed for this first transaction. Thus, everytime NRS or a client would need a secret for an account and be able to reject it, it already does have at least one transaction.

you 2 bring basically the same argument.  We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out.  I say the new clients should implement the restrictions I listed NOW.  Then if the case you bring where the user creates an low-entropy passphrase  then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.

Eventually the new clients will go widestream and security will improve.
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 10, 2014, 03:12:27 PM
 #42662

Wesleyh, Good work on the nxtra.org client.  I would like to be able to use my yubikey with a random static password that I append to a phrase.  If the random number generator is required that may not be possible.  Thoughts?

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Start page:



Can we get only "Login" and "Register" links here without the field  to enter any random password as first option?




I have no idea how a yubikey works, sorry.

Huh? I never mentioned yubikey. I think that's for 2-factor authentication. It won't even work with Nxt as Nxt is local login to NRS.

 

Nomi, Shan, Adnan, Noshi, Nxt, Adn Khn
NXT-GZYP-FMRT-FQ9K-3YQGS
https://github.com/Lafihh/encryptiontest
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 10, 2014, 03:12:47 PM
 #42663

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

Yes, and now calculate the combinations and come back with the number Wink
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 10, 2014, 03:15:37 PM
 #42664


you 2 bring basically the same argument.  We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out.  I say the new clients should implement the restrictions I listed NOW.  Then if the case you bring where the user creates an low-entropy passphrase  then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.

Eventually the new clients will go widestream and security will improve.

Guys, KISS (not literally).

And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be.
BrianNowhere
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile WWW
March 10, 2014, 03:24:38 PM
 #42665

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

Yes, and now calculate the combinations and come back with the number Wink

I have not the math skills to do even this.

1600 * 10 = 16,000  
ok, I'm lost.

I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all.

NXT: 4957831430947123625
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 10, 2014, 03:24:46 PM
 #42666

Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.

What is his draft exactly? Some of his suggestions wouldn't make sense now.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
March 10, 2014, 03:25:02 PM
 #42667

In the end, it would be an inconvenience for large stakeholders but for nothing.

TF is going ahead the way it was planned regardless so why not take these pointless discussions to a new topic?


He requested information and I tried to give it to him.
Meizirkki
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500



View Profile
March 10, 2014, 03:26:22 PM
 #42668

I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 10, 2014, 03:27:26 PM
 #42669

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

Yes, and now calculate the combinations and come back with the number Wink

I have not the math skills to do even this.

1600 * 10 = 160,000  
ok, I'm lost.

I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all.

We make it simple. Imagine each word is a character, as you suggested. But now, for every of the 12 characters we type, we can choose out of 1626 characters.

First character (word): 1626 possibilities
Second character (word): 1626 possibilities
....

Now calculate. You can do it. Math is cool.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
March 10, 2014, 03:27:49 PM
 #42670

Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.

Suggestion:
- SCIP mechanism to count blocks in order to have snapshot every 1440 blocks


Question:
Will snapshots integrated for free?
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 10, 2014, 03:28:13 PM
 #42671

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

Yes, and now calculate the combinations and come back with the number Wink

Since it's open source, everyone knows the dictionary

https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.py

The security shouldn't be based on "secrecy" . It's secure as 12 words from 1626 word choices is equal to 2^128 possible combination.

Nomi, Shan, Adnan, Noshi, Nxt, Adn Khn
NXT-GZYP-FMRT-FQ9K-3YQGS
https://github.com/Lafihh/encryptiontest
bidji29
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
March 10, 2014, 03:29:03 PM
 #42672

I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.

But its really less confusing for newbie than Brainwallet / current wesley implementation

http://www.freebieservers.com/  100% FREE GAME SERVERS
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 10, 2014, 03:30:05 PM
 #42673

I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.

But its really less confusing for newbie than Brainwallet / current wesley implementation

No.
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
March 10, 2014, 03:33:00 PM
 #42674

This good enough for a start page? Shown ONLY ONCE to the user (until the user has logged in), afterwards it's back to the secret phrase input box being shown by default.

Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 10, 2014, 03:33:37 PM
 #42675

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

Yes, and now calculate the combinations and come back with the number Wink

I have not the math skills to do even this.

1600 * 10 = 16,000  

It's 12 words (not 10), so it's 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626


Nomi, Shan, Adnan, Noshi, Nxt, Adn Khn
NXT-GZYP-FMRT-FQ9K-3YQGS
https://github.com/Lafihh/encryptiontest
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
March 10, 2014, 03:33:44 PM
 #42676


you 2 bring basically the same argument.  We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out.  I say the new clients should implement the restrictions I listed NOW.  Then if the case you bring where the user creates an low-entropy passphrase  then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.

Eventually the new clients will go widestream and security will improve.

Guys, KISS (not literally).

And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be.

I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.

you 2 do realize, that right now with no nxtwallet.dat file, AND a "big hint" the we currently have in all NRS clients that there are still people (yes morons, but what can we do) that are losing their NXT?"

how is a .dat file confusing?

the brainwallet function needs to be non-default;  I consider it an advanced feature.  No one can sanely argue this fact, given the big hints we give out but with idiots still ignoring the warnings.
Damelon
Legendary
*
Offline Offline

Activity: 1092
Merit: 1010



View Profile
March 10, 2014, 03:34:21 PM
 #42677

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Thoughts?


Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later.

Do not get sidetracked into that discussion and then wait Smiley

It may not be *perfect* but it's WAY better than what we have.


Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 10, 2014, 03:35:29 PM
 #42678

This good enough for a start page? Shown ONLY ONCE to the user, afterwards it's back to the secret phrase input box being shown by default.



I think that's perfect.

Lets integrate this with next NRS release as default client.

Nomi, Shan, Adnan, Noshi, Nxt, Adn Khn
NXT-GZYP-FMRT-FQ9K-3YQGS
https://github.com/Lafihh/encryptiontest
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
March 10, 2014, 03:36:27 PM
 #42679

I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.

But its really less confusing for newbie than Brainwallet / current wesley implementation

No.

you cant just come in here and say no and leave it at that.  read my argument and refute it.  that is if you want reasonable discourse, otherwise you get ignored.  seriously tell us why "no".
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
March 10, 2014, 03:37:21 PM
 #42680

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Thoughts?


Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later.

Do not get sidetracked into that discussion and then wait Smiley

It may not be *perfect* but it's WAY better than what we have.



I agree, keep main track as is while we discuss the nxtwallet.dat default method.
Pages: « 1 ... 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 [2134] 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!