Bitcoin Forum
August 19, 2019, 05:46:54 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 [2344] 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2755813 times)
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 21, 2014, 04:48:44 PM
 #46861

Then there is no point in creating new accounts.

Yes - that was my understanding from my own modelling.

Still the issue of "randomness" is a key point that I would like to have checked (i.e. how "random" is the block # 1440 blocks in the future).

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 04:49:55 PM
 #46862

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.
Then there is no point in creating new accounts.

Creating blocks in a row that YOU as an attacker control.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 21, 2014, 04:51:09 PM
 #46863

Creating blocks in a row that YOU as an attacker controls.

Yes - this is basically what I modeled in code and mthcl in math (not considering the proposed TF but just the existing approach).

Of course any *model* is just that (so it may not be "good enough" to reflect the *reality*).

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
March 21, 2014, 04:51:32 PM
 #46864

Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k0 but also k1 and k2 and ... and klimit-1 representing the next in the what I would call forging queue.

k0 is the best, followed by k1 and so on.
But at the next moment (when the next block is forged) you decide on only one new entry to the queue? Or you wait until the queue is empty and decide on the whole queue then again?

That is yet to be decided. Smiley

EDIT:
possibilities if could come up with:

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good
Then, if we decide on all queue at once, the algorithm should be changed, because this way you'll not obtain the "correct" forging probabilities (all ki's are different, right?). Think of a situation when there is an account with 50% of all NXT, and limit=100.  Normally this account would forge every second block, but under this approach, it will only forge every 100th.
L5Society
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 21, 2014, 04:53:06 PM
 #46865

suddenly much buying power wazup?

why is nxt going up so much on bter, is there something comming up, NEWS?

NXT will break 0.7 soon.?? Huge lift of

Not sure about the current market dynamics, but...

Bitcoin currently has a 11% inflation rate, in terms of supply. NXT has 0%. If the ratio of bitcoin market cap to NXT market cap were to stay the same, NXT price (denominated in BTC) would appreciate by 11.11% in 2014, 10% in 2015, 9.09% in 2016, 4.17% in in 2017, and 4.00% in 2018. Source: https://en.bitcoin.it/wiki/Controlled_supply

Food for thought.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 04:55:39 PM
 #46866

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.
Then there is no point in creating new accounts.

The point is that an attacker might find a clever combination (trying enough of them out) to control a large enough row.
msin
Legendary
*
Offline Offline

Activity: 1218
Merit: 1001


View Profile
March 21, 2014, 04:57:12 PM
 #46867

Just a few more days until I come back. Is there anyone willing to pay the money for NXT.org?


I canceled 7 domains regarding the Nxt-Ecosystem. After I come back I will concentrate on quality work. Because this is what Nxt needs right now. So please respond to the question above. Smiley

Also I want to redirect NXTarea.com to http://mynxt.org/, Mario is that okay for you? Smiley After a few months I would also cancel this domain then, at this point the users should know that mynxt.org is the new landing page.



wesleyh, I'm not following everything right now. But you mentioned something like client-side-verification at http://nxtra.org/nxt-client-trustless/ . Is that also possible for tipNXT.com (not working right now, because I don't have a server for the client)?


So that someone can type in the wallet password to send the money, but it won't get send to the server. Sure there need to be HTTPS then. But will this makes tipNXT 100% secure?


What if someone hack the server and change the code. Is it possible to create a hash or checksum (with php and crojobs!) of the critical .php files and upload them somewhere on an external site?

Looking forward to having you back Passion_ltc definitely miss your web projects, they were all good!
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 04:57:34 PM
 #46868

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good
Then, if we decide on all queue at once, the algorithm should be changed, because this way you'll not obtain the "correct" forging probabilities (all ki's are different, right?). Think of a situation when there is an account with 50% of all NXT, and limit=100.  Normally this account would forge every second block, but under this approach, it will only forge every 100th.
[/quote]

Do you mean 2) or 3) ?
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 21, 2014, 04:57:43 PM
 #46869

The point is that an attacker might find a clever combination (trying enough of them out) to control a large enough row.

And this is the *concern* that I have always had about the "penalty" approach (as it might actually *help* with this - the simpler the algo the harder to game IMO).

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
March 21, 2014, 04:59:32 PM
 #46870

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good
Then, if we decide on all queue at once, the algorithm should be changed, because this way you'll not obtain the "correct" forging probabilities (all ki's are different, right?). Think of a situation when there is an account with 50% of all NXT, and limit=100.  Normally this account would forge every second block, but under this approach, it will only forge every 100th.
Quote
Do you mean 2) or 3) ?
2
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 05:00:58 PM
 #46871

[...] "penalty" approach (as it might actually *help* with this - the simpler the algo the harder to game IMO).

I do not see, why penalty worsens the situation when trying out 100000000000000000000000000 combinations of raw transactions and potential blocks?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
March 21, 2014, 05:02:18 PM
 #46872

I do not see, why penalty worsens the situation when trying out 100000000000000000000000000 combinations of raw transactions and potential blocks?

Why does one need "100000000000000000000000000 combinations of raw transactions"? Block generation signature doesn't depend on content of the block.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 05:02:59 PM
 #46873

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good
Then, if we decide on all queue at once, the algorithm should be changed, because this way you'll not obtain the "correct" forging probabilities (all ki's are different, right?). Think of a situation when there is an account with 50% of all NXT, and limit=100.  Normally this account would forge every second block, but under this approach, it will only forge every 100th.
Quote
Do you mean 2) or 3) ?
2

Not sure. The next forging queue (that one 100 blocks in the future when each of the 100 forgers forge) might not favor our 50% account.
mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
March 21, 2014, 05:03:04 PM
 #46874

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.
Then there is no point in creating new accounts.

The point is that an attacker might find a clever combination (trying enough of them out) to control a large enough row.
This is, essentially, about breaking the cryptography, right?

Probably, this could be beaten by introducing some extra randomness (e.g., take some quantity that the attacker does not control as a seed, etc.).
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 21, 2014, 05:03:26 PM
 #46875

Why does one need "100000000000000000000000000 combinations of raw transactions"? Block generation signature doesn't depend on content of the block.

Exactly - this seems to have been misunderstood.

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

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


View Profile
March 21, 2014, 05:04:03 PM
 #46876

I do not see, why penalty worsens the situation when trying out 100000000000000000000000000 combinations of raw transactions and potential blocks?

Why does one need "100000000000000000000000000 combinations of raw transactions"? Block generation signature doesn't depend on content of the block.

What does it depend on then?
brooklynbtc
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250

AKA jefdiesel


View Profile
March 21, 2014, 05:04:37 PM
 #46877

Are saying you have basically achieved a way to do trustless, peer to peer cross asset trading?

Yes - I am.


+1 for understatement

SN
S   U   P   E   R    N   E   T
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀   
Uniting cryptocurrencies, Rewarding talent, Sharing benefits..

Blockchain Technology.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
March 21, 2014, 05:05:20 PM
 #46878

What does it depend on then?

Generation signature of previous block and public key of the account that attempts to forge this block.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 21, 2014, 05:05:56 PM
 #46879

This is, essentially, about breaking the cryptography, right?

No - not breaking cryptography - just trying to work out the right balance between "predicting the next forger" and "knowing 100% the next forger" (if you can predict say 2 or 3 then you broadcast your tx to those and you should get an almost instant result but if there is "very little doubt" about who is next then apart from making it easier to *attack* the next node you have a problem with getting "random" things like "tickets for a lottery").

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
March 21, 2014, 05:06:33 PM
 #46880

Not sure. The next forging queue (that one 100 blocks in the future when each of the 100 forgers forge) might not favor our 50% account.
Probability of that is very-very small.  But, anyhow, the number of blocks generated by this 50% account will be strongly reduced, so this would encourage splitting.
Pages: « 1 ... 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 [2344] 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 ... 2567 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!