What I proposed few posts above, is a PoW asset build on top of NXT.
This is possible (and what James is working on) but securing the Nxt network needs to be done in Nxt not in a layer above it.
Topic: NXT :: descendant of Bitcoin - Updated Information - page 704. (Read 2761645 times)
This is possible (and what James is working on) but securing the Nxt network needs to be done in Nxt not in a layer above it.
We need as many nodes as we can get in order to make sure that the network doesn't "fail" (if there are too few nodes then our TPS would drop dramatically and in fact the whole network could be at risk).
TPS is one single aspect. At least for now, we need to ensure database duplication at as many physically distinct places as possible.
Whether these nodes are "pool operators" or "individual forgers" is what we are discussing in regards to the "penalty" situation.
Sorry? What do you mean by penalty situation?
It seems to me that forging is important to a healthy nxt network.
But, forging coins is like trying to find a bitcoin block individually. The small guy does not have much of a chance. Therefore he will not do it.
I have seen talk of NXT forging pools.
Would it not be possible to incorporate some of the mining pool code into NXT? Then the NXT network itself would be a mining pool. I am not a programmer and have no idea what would be necessary.
But, forging coins is like trying to find a bitcoin block individually. The small guy does not have much of a chance. Therefore he will not do it.
I have seen talk of NXT forging pools.
Would it not be possible to incorporate some of the mining pool code into NXT? Then the NXT network itself would be a mining pool. I am not a programmer and have no idea what would be necessary.
NXT itself is PoS. It is a complete system. We do not need PoW code in it.
What I proposed few posts above, is a PoW asset build on top of NXT.
If a node can prove its service to the network, an associated account could receive a portion of that coin.
I think that this is one way of encouraging people to set-up nodes.
Forging does not need to be changed.
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..
sorry is my google translate mouth
CONCLUSIONS
It is clear that as the value of Nxt respect Fiat rises
smaller nodes may cover the costs of forging but the limit will always be the opportunity cost of money referred to immobilize one year funds ..
Don't confuse why we need more nodes, what properties these nodes should have and how an optimal incentive architecture for this contributions is.
We need as many nodes as we can get in order to make sure that the network doesn't "fail" (if there are too few nodes then our TPS would drop dramatically and in fact the whole network could be at risk).
Whether these nodes are "pool operators" or "individual forgers" is what we are discussing in regards to the "penalty" situation.
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.
My point for this discussion is:
Don't confuse why we need more nodes, what properties these nodes should have and how an optimal incentive architecture for running nodes should look like.
Who is currently working on the Decentralized Marketplace / Auction system?
I don't believe anyone, there were talks about using a torrent style system to distribute marketplace which could be loaded to client. If you are interested in developing, there would be quite a large bounty available.
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.
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.
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
@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' ?
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:
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!"
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?
@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' ?
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!
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.
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.
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.
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."
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.
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
Jump to: