NXT :: descendant of Bitcoin - Updated Information

[mthcl]

Maybe, define it this way:

- assume for now that we have a static picture (no transactions between accounts), and there are accounts (nodes) 1,...,N with balances M_1,...,M_N on them;

- the time is discrete, and at each moment k each (active) node j calculates its current weight W_k as a (randomized?) function of M_j and B^j_{k-1} (the previous block in the blockchain that the node j thinks to be "official")

- the network then chooses j_0 such that W_{j_0}>W_i for all i not equal to j_0, and lets the node j_0 forge the block B_k; then L_k=W_{j_0} is the weight of this block.

Now, what I don't really understand, is how a node really determines, which branch is "official"? By looking who has the majority among its neighbors in the network?

Now you lose me with the math (as I said that is not my field) - but let's try and move forwards.

There is "no official" branch.

Each node makes it's own decision about its current chain according to what it sees. So one node can end up on a "fork" and if it goes too far down that fork it may never be able to get back onto the "main chain".

So the "main chain" is the "best chain" in terms of the "weight" of every block in it.

Yes, "official" is a bad term; I meant the "main chain".

Let's, maybe, consider an example, to help me understand it better? Assume the node 1 is run by Emule a rich person, who, nevertheless, wants to destroy Nxt for some reason. Assume also that 1 is connected to 2,3,4 in the network.  At some moment k_0, the node 1 intentionally delays broadcasting its current weight W_1 (should denote that W_1^{k}, but let's not overcomplicate notations), so that at the moment k+1 all nodes except 2,3,4 would think that B_0,...,B_{k_0} is the main blockchain (where B_{k_0} was forged by someone else, say, node 7), while 2,3,4 would think that it is B_0,...,B'_{k_0} (where B'_{k_0} was forged by 1).

Did I get it correctly? If yes, what happens then (assuming 1 wants to continue with its bad behavior)?

[1714610538]

1714610538

[1714610538]

1714610538

[1714610538]

1714610538

[garp]

To summarize: For users with dynamic IPs, you ... still need to set up port forwarding at your router.

Has this always been the case? Or is this the case since a specific version?
What does or does not happen if we don't set up port forwarding?
Having an internal DHCP network behind the dynamic WAN IP address, how can we set up port forwarding  
Or does the server has to run on an internal fixed IP address then
 
It confuses me. May be I lack some IP networking knowledge.
Please, elaborate?

[rickyjames]

NXT FUNDING COMMITTEE VOTE IS COMING MARCH 1

Remaining eligible nominees with as-yet undeclared intentions (PM me if you want off this list):

^[GS]^, 2Kool4Skewl, Arckam_(frmelin), bitcoinpaul,  buybitcoinscanada
ChuckOne, Cointropolis_JustabitTime, Come-from-Beyond
Damelon, davethetrousers, drevil,  EvilDave, ferment, Fry, hughmanwho, Jean-Luc,
jl777, Klee, landomata, laowai80,  msin, mww
nexern, opticalcarrier, Pandaisftw,  PeercoinEnthusiast, pinarello, Pouncer,  Ricot, salsacz
SecondLeo, smaragda,  Uniqueorn, VanBreuk,  ZeroTheGreat


Something Zahlen said:  A candidate does not need to be good at writing English. Some candidates may not have English as their mother tongue. If you're voting, don't confuse lots of writing for ability to judge the worth of a project. Remember that ultimately the committee's job is to decide which projects get funded.

If you are on this list and want to be on a NXT funding committee, go here:

https://bitcointalk.org/index.php?topic=479167.msg5280476#msg5280476

Background:

https://bitcointalk.org/index.php?topic=345619.msg5280786#msg5280786

Good luck to these nominees who have declared themselves candidates:


NXTmarketingfund: allwelder, Damelon,  Mario123, Asian Prepper, joefox, brooklynbct, CoinTropolis_NiftyNikel
NXTtechdevfund: EmoneyRu, Anon136, l8orre, abuelau
NXTinfrastructurefund: rickyjames, chanc3r


Yeah, you may have seen this before.  I'll be putting it up every ten pages or so.  It's one of those "legitimate, transparent process" things.

[brooklynbtc]

CONCLUSIONS

is clear that as the value of Nxt respect Fiat up

is smaller nodes may hold but the limit will always be the
opportunity cost of the money referred to immobilize one year..

 

[ChuckOne]

Why?

I am not so sure my first idea was a good one but my concern is that if most people become uninterested in forging it could make the network less resilient in the (hopefully unlikely) case of pool servers being shut down by authorities in particular.

So I am quite happy to drop that idea but I still think the problem of "penalty" needs to be considered as well as the problem of having "too much forging power" amongst a small number of pools.

During catching up I got an idea. I'd like some feedback on that:

We should not confuse two different issues: I1) finding consensus and I2) stabilizing the network. Each of these have two different purposes, therefore two different audiences and should therefore have two different incentive mechanisms. We cannot urge people to do something, we only can encourage them by offering rewards.

I1) TF is designed to do that. Transactions fees are the reward/incentive.

I2) More nodes will make the network more secure against switching nodes off. Reward for running a node: X

One could think of a special asset X that is only available for those running verifiable DIFFERENT nodes (in terms of databases, hardware, IPs etc). These accounts will get a portion of X for running a node.

[brooklynbtc]

Shut up, Emule. You have no sense of humor. Go drink your aperitifs with your friends.

I don't know if thats a lost in translation thing, but man its a good insult!

PS I love aperitifs.

[opticalcarrier]

To summarize: For users with dynamic IPs, you ... still need to set up port forwarding at your router.

Has this always been the case? Or is this the case since a specific version?
What does or does not happen if we don't set up port forwarding?
Having an internal DHCP network behind the dynamic WAN IP address, how can we set up port forwarding  
Or does the server has to run on an internal fixed IP address then
 
It confuses me. May be I lack some IP networking knowledge.
Please, elaborate?

thats what he says, but I believe that he means that if your intent is to run a public node then you need the port forward on your WAN router.  Im using 0.8.1e at home, with sharmyaddress set to false, and dont have a port forwarded, am even using tor, and Im still getting updated blocks from peers.

[l8orre]

Why dont we update the NXT network?

I am only waiting for client developers to say they fully support the 0.8 branch, and to have the user friendly installer packages ready, before announcing it stable. I don't think it is unstable at all.

We have to move to the 0.8 branch before I can start working on incompatible features such as adding transaction type for fractional Nxt amounts.

This is developing at quite a stiff pace!

@JL - please give me a hint: My client currently uses all 'GET' requests, but I have already successfully used 'POST' with the same module (pyhton 'requests') elsewhere.

My approach would be to move from 'GET' to 'POST' for ALL requests, because if it is all one cast there is less chance for mixups to creep in.

Will that be possible wth 0.8.+ ? Or will I run into trouble because some api calls only accept 'GET', and others only 'POST' ?

Thanks, l8orre

[CIYAM]

Did I get it correctly? If yes, what happens then (assuming 1 wants to continue with its bad behavior)?

I think you've got it correctly - the reason that 1 can't continue this behavior successfully depends upon his control of the future blocks (which he can't actually *control by himself* due the random nature of crypto hashes).

So the *evil block forger* actually needs *evil friends* to help him. If he has enough friends then he can win but the actual probability of this is why we need a math guy.

[punkrock]

Are other people having problems with withdrawal from Dgex?  I did instant BTC withdrawal last week (5 days) and still haven't got any BTC.  It showed up as processed on my account with a transaction ID that appears nowhere on blockchain explorer.

I am trying to withdrawal my BTC from MT.SUX since a week with no success. I only get the message: "Transfer queue is currently not accepting more requests, please retry later."

[msin]

Throwing out some suggestions here on prevention of centralization due to leased forging power...

Set a hard limit on size of a pool's effectiveBalance consisting of leased power.  Maybe 5M or 10M NXT or something like that?  We may even want to set a limit to max size of a single account's effectiveBalance, such that if a single account's balance is higher than, say, 10M NXT, then its effectiveBalance is limited to 10M.  Users could then choose to split accounts and forge on different machines that would then provide a measure of redundancy.

And since these countermeasures *could* be broken via configurations of software/hardware if the pool operator or user *really* wanted to, I think we still should pursue the TF option of selecting secondary, tertiary and even 4th and 5th accounts that could quickly forge a block should higher priority accounts fail to forge in a quick manner.

+1, limit Pool size to 1% of total Nxt is a good idea.

[ChuckOne]

The issue here is think is: it is not that we want the same person having several nodes but different persons having a node. Redundancy and mutual control is the key.

This doesn't parse - care to explain it again?

Of course.

The point in having MORE NODES is to have the network more decentralized.

1 person having multiple nodes == 1 node effectively. Can be seized, can be killed, can be destroyed, very easily.

So basically, we want more nodes by more different people == 1 person <-> 1 node BUT many people in order to prevent the issues describe above.

[l8orre]

I'm updating the testnet...

yummie - can't wait for them testNXT!






yesyesyes I know they're not real, but they are so sweet and sticky anyways!

[Jean-Luc]

@JL - please give me a hint: My client currently uses all 'GET' requests, but I have already successfully used 'POST' with the same module (pyhton 'requests') elsewhere.

My approach would be to move from 'GET' to 'POST' for ALL requests, because if it is all one cast there is less chance for mixups to creep in.

Will that be possible wth 0.8.+ ? Or will I run into trouble because some api calls only accept 'GET', and others only 'POST' ?

Yes, you can use POST for all requests.

[Jean-Luc]

To summarize: For users with dynamic IPs, you ... still need to set up port forwarding at your router.

Has this always been the case? Or is this the case since a specific version?
What does or does not happen if we don't set up port forwarding?
Having an internal DHCP network behind the dynamic WAN IP address, how can we set up port forwarding  
Or does the server has to run on an internal fixed IP address then
 
It confuses me. May be I lack some IP networking knowledge.
Please, elaborate?

Port forwarding is only needed if you do want to receive connections from others. You can always make outgoing connections and this is sufficient. If you don't want to set up port forwarding and receive incoming requests, set nxt.shareMyAddress=false, so that you don't unnecessarily run a peer server on port 7874.

[Damelon]

I'm updating the testnet...

yummie - can't wait for them testNXT!






yesyesyes I know they're not real, but they are so sweet and sticky anyways!

Caption: "I will you in your sleep if you tell anyone!"

[ChuckOne]

@JL - please give me a hint: My client currently uses all 'GET' requests, but I have already successfully used 'POST' with the same module (pyhton 'requests') elsewhere.

My approach would be to move from 'GET' to 'POST' for ALL requests, because if it is all one cast there is less chance for mixups to creep in.

Will that be possible wth 0.8.+ ? Or will I run into trouble because some api calls only accept 'GET', and others only 'POST' ?

Yes, you can use POST for all requests.

Huh? Why is that?

Come on. If I am a developer, I should be able to tell GETs and POSTs apart. Otherwise, it's more like:

[GCInc.]

Are other people having problems with withdrawal from Dgex?  I did instant BTC withdrawal last week (5 days) and still haven't got any BTC.  It showed up as processed on my account with a transaction ID that appears nowhere on blockchain explorer.  I got no BTC and they refuse to resend because they say it might send twice even though they know that I got nothing and obviously wanted the BTC fast.  I don't know if this is a transaction malleability issue or if they are f*ing up and screwing people, but people should be aware don't do instant BTC withdrawal from Dgex... They put up no warning even though they know of the problem.  WTF.  Other possibility is that they are just keeping my money and using confusion about transaction malleability as an excuse.  Sorry to be negative and pissed off but don't know of other reasonable recourse after exchanging emails with them and getting no reply to the last one.

Likely nobody of your readers is having such a problem - we have 4 withdrawals out of hundreds in such status because they include "transaction malleability" rigged inputs in the output transaction, thus remaining in unclear state on our Bitcoin daemon until we manage to perform some tech black magic to extract the transactions to clear whether the account holder has anything to do with the input rigging. As you may know the bitcoin network brings up some pretty nasty surprises on occasion, it's unfortunate you are one of the affected customers this time. That's no excuse, support should have explained it to you and this is not the right thread to complain about DGEX account problems. Thanks

[CIYAM]

So basically, we want more nodes by more different people == 1 person <-> 1 node BUT many people in order to prevent the issues describe above.

I don't think this adds much to the discussion but thanks for the input.

[ChuckOne]

Why?

I am not so sure my first idea was a good one but my concern is that if most people become uninterested in forging it could make the network less resilient in the (hopefully unlikely) case of pool servers being shut down by authorities in particular.

So I am quite happy to drop that idea but I still think the problem of "penalty" needs to be considered as well as the problem of having "too much forging power" amongst a small number of pools.

During catching up I got an idea. I'd like some feedback on that:

We should not confuse two different issues: I1) finding consensus and I2) stabilizing the network. Each of these have two different purposes, therefore two different audiences and should therefore have two different incentive mechanisms. We cannot urge people to do something, we only can encourage them by offering rewards.

I1) TF is designed to do that. Transactions fees are the reward/incentive.

I2) More nodes will make the network more secure against switching nodes off. Reward for running a node: X

One could think of a special asset X that is only available for those running verifiable DIFFERENT nodes (in terms of databases, hardware, IPs etc). These accounts will get a portion of X for running a node.

bump for @CIYAM Open

I think this should explain why I think more nodes are not necessarily better. Nodes have to be physically disconnected from each other.