Bitcoin Forum
February 03, 2023, 10:23:35 AM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 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 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761351 times)
redsn0w
Legendary
*
Offline Offline

Activity: 1778
Merit: 1042


#Free market


View Profile
March 09, 2014, 11:22:25 AM
 #42221

Did you want some TestNxt ?
1675419815
Hero Member
*
Offline Offline

Posts: 1675419815

View Profile Personal Message (Offline)

Ignore
1675419815
Reply with quote  #2

1675419815
Report to moderator
1675419815
Hero Member
*
Offline Offline

Posts: 1675419815

View Profile Personal Message (Offline)

Ignore
1675419815
Reply with quote  #2

1675419815
Report to moderator
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675419815
Hero Member
*
Offline Offline

Posts: 1675419815

View Profile Personal Message (Offline)

Ignore
1675419815
Reply with quote  #2

1675419815
Report to moderator
1675419815
Hero Member
*
Offline Offline

Posts: 1675419815

View Profile Personal Message (Offline)

Ignore
1675419815
Reply with quote  #2

1675419815
Report to moderator
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 09, 2014, 11:23:04 AM
 #42222

I think entropy from mouse is needed for javascript (like wesley client) -- not for Java's SecureRandom

As for words, as I said, don't use cryptic words from diceware. 1626 simple words dictionary will just work fine for 128-bit entropy.


Actually, newest browsers have crypto.getRandomValues - so no mouse movement needed in those cases. Of course still necessary for older browsers.

Well, even if it is not technically necessary for most of the browsers, we should use the mouse movement because

1. With this, we make sure every user (no matter which browser) has a secure account (using mouse movement only on older browsers gives no common picture of the client on every computer. looks insecure)
2. It gives a secure feeling because the user is part of the process

Hmm, anyone else's input on this? I believe relying on system cryptography is always better than having the user doing something (mouse movement). It will be available though, for older browsers.

Its not really needed if cryptographically secure number generator is available,  but it won't really hurt. It will just add more entropy if you start with crypto gen and the user adds more entropy with mouse movements.






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 09, 2014, 11:24:15 AM
 #42223

Parallel blockchains, same NXT tokens?

No - different tokens (NXT and NXG in my illustration).



Then this won't work.


As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.


bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 09, 2014, 11:24:58 AM
 #42224

Its not really needed if cryptographically secure number generator is available,  but it won't really hurt. It will just add more entropy if you start with crypto gen and the user adds more entropy with mouse movements.


I really like it because it is secure, user friendly & the user feels the security.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1028


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 09, 2014, 11:26:49 AM
 #42225

Then this won't work.


As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.

True - you would use atomic cross-chain txs to move between NXT and NXG (something that AT will be able to provide).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
redsn0w
Legendary
*
Offline Offline

Activity: 1778
Merit: 1042


#Free market


View Profile
March 09, 2014, 11:27:41 AM
 #42226

I Found a bug  in the client 0.8.8 (test)

Code:
{
    "balance": 100097400,
    "effectiveBalance": -100,
    "unconfirmedBalance": 100097400
}

Why the effective balance is :


 "effectiveBalance": -100,
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 09, 2014, 11:30:56 AM
Last edit: March 09, 2014, 11:42:22 AM by Eadeqa
 #42227

I have not heard that before, please do point at any references if you know of any. If it is true it should not be used, you are right.
In that case rand.nextInt(ARRAY.length) would be the safer bet.

I don't have a reference, but say you want to map a random value R between 0 and 15 to a value P between 0 and 9 and use P=(R modulo 10):

Code:
R   P
0   0
1   1
2   2
3   3
4   4
5   5
6   6
7   7
8   8
9   9
10  0
11  1  
12  2
13  3
14  4
15  5

As you see, having the input value R completely random, doesn't mean that P is as random, since you will get values 0 to 5 twice as often as values 6 to 9.

I picked the example to show the problem. With the very large ranges for R (e.g. integer) and very small ranges for P (e.g. 0 to 8191), the problem might just be a very theoretical one.


think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1

You can generate a 128-bit number (totally secure using secure random) and then convert it into words

I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words

This would be same as representing a binary number as hex or decimal.

 The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker


This by the way means only 12 words are needed to convert any 128-bit number into words


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 09, 2014, 11:35:48 AM
 #42228

Then this won't work.


As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.

True - you would use atomic cross-chain txs to move between NXT and NXG (something that AT will be able to provide).


But then it is possible, so my statement is false Huh
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 09, 2014, 11:37:47 AM
 #42229

I think BCNext talked about different fees for different transaction speeds (and/or security?). What are the implications of our two-blockchain-solution (I keep it simple for now, so only two)?

Maybe: We would have the slow one for the average user (minimal fee) and the high speed one for businesses (more fee).
MadCow
Hero Member
*****
Offline Offline

Activity: 655
Merit: 500



View Profile
March 09, 2014, 11:40:44 AM
 #42230



Unique is being blunt as fuck here, but he does have a point. More big stakeholders opening their wallets would be good, even if only to show that they do give a fuck. But we've down this road before without much results, we can't force people to fund NXT even if it is in their own best interest to do so. So lets put selfish stakeholders on the list of things to ignore, for the moment.



I thought a group of big stakeholders started a fund managed by rickyjames for jl777 to use on all his projects. Correct me if I'm wrong, but I think some of those donations were quite large. I think klee and pouncer (and others?) have funded other projects too (one involving CIYAM?).

Who & what need funding right now who aren't getting it, or aren't just about to get it from the three committees?

From my reading of this thread it sounds like we're still in the planning stage, and we already have funds for the three committees, plus the extra private funds for jl777 etc on the side.

Instead of criticizing the big stakeholders, why not focus on getting agreement on the final plan/direction for NXT, then organise that into a set of projects with a shopping list, then ask for stakeholder donations when they know who and what they're paying for.

I think many fat cats will contribute when the time comes, and I base that on past evidence. There's too much bad blood at the moment IMO, and we don't have a clear road map with a leadership group. Save the stakeholder bashing for if & when the leadership group's pleas for donations for specific projects are being ignored. Try and stay positive on the main task - the NXT roadmap!
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1028


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 09, 2014, 11:40:55 AM
 #42231

But then it is possible, so my statement is false Huh

My bad - yes indeed it is possible but it would not be something you could do quickly (it would be a process with a few steps).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Jean-Luc
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile WWW
March 09, 2014, 11:41:13 AM
 #42232

I Found a bug  in the client 0.8.8 (test)

Code:
{
    "balance": 100097400,
    "effectiveBalance": -100,
    "unconfirmedBalance": 100097400
}

Why the effective balance is :


 "effectiveBalance": -100,

Not a bug, effectiveBalance can be negative.

lead Nxt developer, gpg key id: 0x811D6940E1E4240C
Nxt blockchain platform | Ardor blockchain platform | Ignis ICO
verymuchso
Sr. Member
****
Offline Offline

Activity: 421
Merit: 250


HEAT Ledger


View Profile
March 09, 2014, 11:41:19 AM
 #42233

think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1
You can generate a 128-bit number (totally secure using secure random) and then convert it into words
I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words
This would be same as representing a binary number as hex or decimal.
The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker

Just out of curiosity. Could you give a brief example, I don't immediately see how to implement this.

voldemort628
Full Member
***
Offline Offline

Activity: 155
Merit: 100


View Profile
March 09, 2014, 11:42:38 AM
 #42234

Did you want some TestNxt ?

423539966622014338
please.
cheers Smiley

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
▐ CRYPTI▐
a Node.JS coin built from scratch. With Proof of Time, Purchase and Identity. Custom blockchains and much more!
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
chanc3r
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
March 09, 2014, 11:45:14 AM
 #42235

I think BCNext talked about different fees for different transaction speeds (and/or security?). What are the implications of our two-blockchain-solution (I keep it simple for now, so only two)?

Maybe: We would have the slow one for the average user (minimal fee) and the high speed one for businesses (more fee).

the speed of transaction processing is based on the availability of a processor, the time to get the transaction to it, the time to process and the time for the requestor to see the result.

I don't see how parallel block chains address any of these issues other than making reconciliation of accounts harder because transactions are spread across multiple chains...

EDIT: and I agree with BCNext, see earlier post, the faster you want the tx confirmed the higher the fee %age is a possible model but who pays the higher fee... the merchant wanting an instant confirmation or the buyer....?? both models exist

bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 09, 2014, 11:48:07 AM
 #42236

But then it is possible, so my statement is false Huh

My bad - yes indeed it is possible but it would not be something you could do quickly (it would be a process with a few steps).


So choosing between these two block chains when making a transaction makes, at first sight, no sense. It will be technically possible, but that's it for now.

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?
ZeroTheGreat
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 09, 2014, 11:51:11 AM
 #42237

I don't think many people will bother with forging if this is how it is.

Exactly

Hi, I would share my witness Wink

I bought 400.000 NXT a month ago and forging. But I got nothing from this Wink

If I bought so many it was to forge some more. But the reward looks low or inexistent. Look like only extra rich can get something.

The TX fee is okay to me, it's helping the coin to spread between forgers. If we reduce this fee, it will even harder to get something from forging.

I don't know the politic about NXT futur, 2200 pages is to high reading for me ^^ but peoples will not help to forge if they have to spend thousands dollars to receive almost nothing.
It'd be placed at first page:

Monthly ROI% of forging now about 0.1-0.25%. Dispersion of income is inverse propotional to propotion of your NXTs to all NXTs those exist. ROI%'ll change proportionally to business activity on network. So there's no reason it'll change till activity ~ current activity.

Relative amount of fees can't change ROI% drastically itself. We need to find an equilibrium. Last time community voted for decreasing fees from 1 NXT to 0.1 NXT for common txs. Devs'd respond. And then, if changes'll be implemented, we all'll find out how activity'll change.


Everyone, who's thinking about forging like a business'd consider this info. It gives straight answers: forge with this ROI%, try to speed up activity or just stay away.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1028


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 09, 2014, 12:01:06 PM
 #42238

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?

Okay - well technically I think parallel chains are not going to be very difficult as we *already have one* (it's called "test net") so we are not talking about a huge amount of extra coding that would be required to be performed.

The main thing is going to be to work out what "features" are going to be made available to a parallel chain and what differences in rules (such as say fees) might apply and in particular to get community support for it.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
March 09, 2014, 12:02:00 PM
 #42239

think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1
You can generate a 128-bit number (totally secure using secure random) and then convert it into words
I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words
This would be same as representing a binary number as hex or decimal.
The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker

Just out of curiosity. Could you give a brief example, I don't immediately see how to implement this.

Sure, but I think it's all unnecessary.  Why not just call SecureRandom 12 times to pick 12 random numbers (range  0 to 1625 ). You can use that to choose 12 random words from array. That will be pretty simple and no security/implementation complications.  The words would be chosen randomly and entropy would be 128-bit.





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 09, 2014, 12:05:43 PM
 #42240

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?

Okay - well technically I think parallel chains are not going to be very difficult as we *already have one* (it's called "test net") so we are not talking about a huge amount of extra coding that would be required to be performed.

The main thing is going to be to work out what "features" are going to be made available to a parallel chain and what differences in rules (such as say fees) might apply and in particular to get community support for it.


Ok, we keep the atomic cross chain transaction possibility in our mind but first talk about all technical possibilities which lead to real world implications of parallel chains.

For example: Your idea is a mix of technical possibilities (raspPis can forge, different fees) and real world implications (we can market a green nxt and forgers could be happy).

What else?
Pages: « 1 ... 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 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 ... 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!