starik69
Legendary
Offline
Activity: 1367
Merit: 1000
|
|
February 24, 2014, 10:49:27 AM |
|
Why in 0.8.0e shareMyAddress is the same as peer networking? Why i cannot run peer networking without sharing my address as it have been before?
If you have an address that other peers can connect to, you can't really prevent that from being shared. Even if your peers don't share it with each other, you don't control which peers you connect to. So when you connect to one peer, after a while you request from it all other peers that it knows about. Then, you start connecting to them one by one - and all of them get to know your address directly from you. So it doesn't make sense to announce a public address, yet to set sharing to false. It will still get known, only a bit slower. In fact, in 0.8.1, I added a feature so that setting nxt.myAddress is optional and only strictly needed if you use a non-default port. If you don't set nxt.myAddress, but nxt.shareMyAddress is still true (the default), when you connect to a peer he will see the address your request is coming from, and at a later time try to connect to this address at the default port (unless you have set nxt.myAddress to something else, in which case it will try to connect to your announced address). If it succeeds, it will treat your peer as if nxt.myAddress has been set to the address your connection was seen as coming from. And also share this address with others so they can also connect to you. This way you don't need to worry about what is the external IP of your router, and especially if it ever changes for those with dynamic IPs. If you don't want this to happen, set nxt.shareMyAddress to false. In this case, the peer networking server will not be started at all as nobody will be attempting to connect to you. You can of course still make outgoing requests and receive responses to them. Still don't understand. In versions <0.8.0 when i announce a public address but set sharing to false other node will connect to me only after my node first connects to it. In 0.8.0 such logic of behavior is impossible. Is this true?
|
|
|
|
Jean-Luc
|
|
February 24, 2014, 10:54:30 AM |
|
Still don't understand. In versions <0.8.0 when i announce a public address but set sharing to false other node will connect to me only after my node first connects to it. In 0.8.0 such logic of behavior is impossible. Is this true? Yes, this is true. You don't have control over which nodes you connect to, so why would you need such behavior? It would only make sense if you can define a whitelist of nodes to connect to, but currently you can't do that. Your node will keep trying to connect to whatever list of peers it receives from the others, and telling them your public address itself, how is that different from allowing the peers to share it amongst themselves too?
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 24, 2014, 10:59:33 AM Last edit: March 05, 2014, 08:18:54 AM by xyzzyx |
|
My main concern is that simple economics will likely lead to a small number of "super nodes" because I think *most* stakeholders will lease their forging rights to pools (why wouldn't you want to get money for doing absolutely nothing?).
So the problem is that if those pools are suddenly shut down (due to court order lets say) then the transaction confirmation rate is going to slow down *dramatically*.
It would be in a merchant's best self-interest to run a node. The reason is that his payment transaction would be signed by his customer and handed directly to the merchant who would then be responsible for guaranteeing his payment makes it into the Nxt network as fast as possible without being orphaned. We need to start thinking about how to accomplish the first part -- locally signing of a transaction and handing-off to a merchant -- in a way that is as invisible to the end-user as possible. It should "just work" from the customer's perspective. However, I've been doing some thinking about TF for a while now but I've not said much because my ideas are still a bit half-baked and I don't know if they align with BCNext's ideas for TF, but I'll make a longer detailed post in a few days when I've organized it. I think 1000 TPS is no big deal even with a few forging nodes, and high-frequency trading is possible in the distributed exchange. Also, it would make forgers happier than they are at the moment even with tiny transaction fees. I need to get other's (your's, reader) feedback on these ideas to see where I may be thinking incorrectly. Give me a few days to make a coherent post on it.Edit: changed my mind. But local signing and handing-off to a merchant should be a top priority at the moment, IMHO. This should include writing plugins for cart software like ZenCart and WooCommerce.
|
"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
|
|
|
igmaca
|
|
February 24, 2014, 11:03:41 AM Last edit: February 24, 2014, 11:28:04 AM by igmaca |
|
My gut feeling is that forging NXT will never be profitable for anybody.
I think it is going to be profitable for a few pools mostly and I predict that in the future most forging power will be locked up in ATs that act as "interest bearing accounts". It is up to the community to make sure that we don't just end up with a small number of pools and a few hundred hobbyists. my proposal is to just give in to the pools forging fees rights. Not forging power. Not funds forging power and funds stay in bob account forging fees rights stay in pool if bob wants. if bob forge and forging fees rights are in the pool bob must split forging fees with other people in the pool proportionally with amount of funds in this moment. the pools are created automatically by the network grouping the accounts. for example a size of 100000 nxt this would lead to forge every 2 to 3 days that is a reasonable value to maintain interest little hobbyistsI think for that direction is the right solution. with this solution the network will always be extremely decentralized and every body have the same opportunities to forge. you just have to adjust the transaction fee for the annual return to forge all year continuously is equivalent to the cost of maintaining the node. if for example it is estimated that with 10000 nodes is enough then we must assess how much maintaining 10000 nodes for a year and evaluate the number of transactions in the year and adjust the fees. For example John have 90000Nxt Mary have 9900 Nxt Bob Have 100 Nxt Total 100000 Nxt 1440 blocs per day 52.6 blocs per year with 100000 Nxt fee per bloc (For example) 100 Profit per year 5.3% 5.3% must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost) dividing the total number of coins that are forging nxt at all times in sections 100000 nxt automatically. accounts with more than 100000 nxt forge individually. forge worldwide every 2 to 3 days.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 24, 2014, 11:05:33 AM |
|
Another issue that I think needs to be carefully considered is the "penalty" for not forging.
I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this).
And where I see it as being problematic is that our little hobbyists are quite likely to just switch off their forger for a day if they get penalized. It may even piss them off enough to "give up forging" once again potentially hurting our network.
So in summary I think that we "don't need it" and IMO we would be better off without it.
|
|
|
|
verymuchso
Sr. Member
Offline
Activity: 421
Merit: 250
HEAT Ledger
|
|
February 24, 2014, 11:06:10 AM |
|
What I can do is make Nxt.shutdown() public and not add any shutdown hooks myself, when started using init(), only when started using main(). Then whoever calls init() has the responsibility to add a shutdown hook or call shutdown(). I don't know how your restart works, but unless the jvm is really shutdown and started again, init() is unlikely to work as expected after a shutdown(), because of all the static initializers and final variables I rely on.
Perfect! Our client is built as an Eclipse RCP app, those come with a native launcher that controls the jvm. Thats how Eclipse can be *restarted* when you installed a new plugin. It's just that jvm shutdown seems to not go so gentle. The nxt-default.properties has to be there. I don't throw exceptions if nxt.properties is missing. Why do you not want to use nxt-default.properties? It only needs to be in the classpath, it can be hidden from the user. ... This cannot be done in init, because properties must be loaded before any other classes attempt to get them using Nxt.getStringProperty() etc., such as the Logger initializing its debug and enableStackTraces as static final. Allowing additional properties overrides in the init() was not such a good idea. If you want to add listeners to BlockchainProcessor for example, before init() has been called, it still needs to see the correct values of all properties - so it is too late to set them in init().
In an RCP application everything gets bundled as an OSGI bundle/plugin, we also do this for nxt. It's so we can deploy updates to nxt as only one updated plugin. This however leads to troubles since an OSGI bundle is usually a jar and it's kinda hidden away in the plugins folder (not easily reachable for end users). Currently we already have a properties file in the install folder root (which is recognizably named after the client) it would be most ideal if we can use that properties file to allow for user overwrites, this is also the case since we are planning to support multiple crypto currencies in the client and all user settings could go there. I'm not sure if `ClassLoader.getSystemResourceAsStream("nxt.properties");` will include the install directory in it's search path since nxt is *in* it's own plugin which is loaded by the OSGI classloader (maybe it will). Ideal would be if somehow you could make the location of nxt.properties dynamic. Easiest in our case would probably be a simple property (System.getProperty('nxt.Nxt.config')) so we can pass the location as jvm argument or set it ourselves in code that loads before the nxt plugin is activated.
|
|
|
|
bitcoinpaul
|
|
February 24, 2014, 11:07:44 AM |
|
But local signing and handing-off to a merchant should be a top priority at the moment, IMHO. This should include writing plugins for cart software like ZenCart and WooCommerce.
+1 At least CfB is on local signing (but not right now?) and some dudes are implementing shopping cart modules for Nxt for now.
|
|
|
|
bitcoinpaul
|
|
February 24, 2014, 11:10:06 AM |
|
Another issue that I think needs to be carefully considered is the "penalty" for not forging.
I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this).
And where I see it as being problematic is that our little hobbyists are quite likely to just switch off their forger for a day if they get penalized. It may even piss them off enough to "give up forging" once again potentially hurting our network.
So in summary I think that we "don't need it" and IMO we would be better off without it.
Without some sort of penalty, nodes can do what they want. Or do I misunderstand you?
|
|
|
|
igmaca
|
|
February 24, 2014, 11:19:07 AM |
|
Another issue that I think needs to be carefully considered is the "penalty" for not forging.
I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this).
And where I see it as being problematic is that our little hobbyists are quite likely to just switch off their forger for a day if they get penalized. It may even piss them off enough to "give up forging" once again potentially hurting our network.
So in summary I think that we "don't need it" and IMO we would be better off without it.
I agree with you little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost)
|
|
|
|
EvilDave
|
|
February 24, 2014, 11:22:28 AM |
|
Last minute opportunity to attend/give talk Ethereum/Bitcoin meetup in Amsterdam. Thursday 27 Feb!Like it says above, just had a mail from Bas de Lange (Bitcoin meetup organiser) asking if I'd be interested in giving a talk this week at this meetup event: http://bitcoinobserver.com/news/2014-02-12-Ethereum-Bitcoin-Amsterdam-Meetup-ZB45-Makerspace.htmlI'm not going to be even slightly available, (and i dont think that I have the presentation skills or NXT in-depth knowledge needed). Might be useful to attend, though, if there any A'dam/NL NXT'ers interested. If you're up for it, u can either PM me and/or get in touch with Bas directly. On the network nodes/bandwidth/forging question:Can someone audit the entire NXT network over the next few days and come up with some solid information/statistics about what we actually have running right now? I can get estimates from PeerExplorer / NRS, but more in-depth info would be good. Public/private nodes, forging or not, VPS or stand-alone...estimates of current transaction capacity ( ? TPS)and power consumption would also be nice. Once we know what we actually have, and how well it performs, we can move on to plan for what we need. Any NXT dudes with the required skills want to volunteer?
|
|
|
|
igmaca
|
|
February 24, 2014, 11:40:28 AM |
|
Another issue that I think needs to be carefully considered is the "penalty" for not forging.
I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this).
And where I see it as being problematic is that our little hobbyists are quite likely to just switch off their forger for a day if they get penalized. It may even piss them off enough to "give up forging" once again potentially hurting our network.
So in summary I think that we "don't need it" and IMO we would be better off without it.
I agree with you little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost) actually a person with 1900 Nxt forge the end of a year one block. (if 1440 blocks per day are forged) therefore will get an annual return of funds to keep their forging. is more perception than having to wait a whole year in the worst case which can not maintain the interest to little hobbyists
|
|
|
|
mephy
Newbie
Offline
Activity: 33
Merit: 0
|
|
February 24, 2014, 11:41:07 AM |
|
little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost)
I think forging should be more interactive. For example: Someone started a node with 10000 NXT, waited for 1 week, still 10000 NXT -> Boring. plus no idea, if it actually worked or not, maybe even a false run. Other example: Someone started node with 10000, in 6 hours he get 10000.0001 Pool functionality but with no risk. There are lots of people who can run a node at work with no cost (for them ). We should show them they can earn some doing nothing. I dont start bitcoin / other miner coz a lot of cooler noise. NXT makes no noise
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 24, 2014, 11:41:18 AM |
|
Without some sort of penalty, nodes can do what they want. Or do I misunderstand you?
It won't matter whether they forge or not (others will) so no need for a penalty IMO. Understand that when TF is completed you can expect to be penalised often as you will normally be competing with 3 or 4 other nodes (at least that is my understanding). I know that I am simply going to be putting my NXT savings into an interest bearing AT (which I am going to write of course) which invests in a pool (with the ability to switch pools via an AM) rather than bother running a node myself (although in the long term I will probably end up investing in some hardware as well).
|
|
|
|
igmaca
|
|
February 24, 2014, 11:48:22 AM |
|
little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost)
I think forging should be more interactive. For example: Someone started a node with 10000 NXT, waited for 1 week, still 10000 NXT -> Boring. plus no idea, if it actually worked or not, maybe even a false run. Other example: Someone started node with 10000, in 6 hours he get 10000.0001 Pool functionality but with no risk. There are lots of people who can run a node at work with no cost (for them ). We should show them they can earn some doing nothing. I dont start bitcoin / other miner coz a lot of cooler noise. NXT makes no noise I sincerely see the solution very easy
|
|
|
|
EmoneyRu
|
|
February 24, 2014, 11:51:16 AM |
|
After discussing this issue with CIYAM Open I got that we indeed have a problem here. If users will just lease their power and forget then one day Nxt network may die.
Why? Some target to the moon magic? Who's chain would be prioritized? I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this). Just let me forge with some generated time limited code made from key phrase and I'll give it to you. Right now I don't want to cron forging with the main key. There are no hardcoded nxt.wellKnownPeers in the default properties files. You are supposed to set those to your own preferred peers in nxt.properties. However, if none are set, a random selection of nxtcrypto.org and nxtbase.com public nodes will be used.
They are managed by 2 people only. Anything can happen. It'd better to have some predefined peers in your distribution. On start just combine them and random selected ones.
|
|
|
|
igmaca
|
|
February 24, 2014, 11:54:03 AM |
|
After discussing this issue with CIYAM Open I got that we indeed have a problem here. If users will just lease their power and forget then one day Nxt network may die.
Why? Some target to the moon magic? Who's chain would be prioritized? I don't see it as being necessary in that any advantage of "not forging" would require significant amount of collusion IMO to be of financial benefit (maybe someone with some math skills can work on this). Just let me forge with some generated time limited code made from key phrase and I'll give it to you. Right now I don't want to cron forging with the main key. There are no hardcoded nxt.wellKnownPeers in the default properties files. You are supposed to set those to your own preferred peers in nxt.properties. However, if none are set, a random selection of nxtcrypto.org and nxtbase.com public nodes will be used.
They are managed by 2 people only. Anything can happen. It'd better to have some predefined peers in your distribution. On start just combine them and random selected ones. no power to forge not share. share your fees if you forges is not the same with respect to network security
|
|
|
|
starik69
Legendary
Offline
Activity: 1367
Merit: 1000
|
|
February 24, 2014, 11:55:42 AM Last edit: February 24, 2014, 12:09:51 PM by starik69 |
|
Still don't understand. In versions <0.8.0 when i announce a public address but set sharing to false other node will connect to me only after my node first connects to it. In 0.8.0 such logic of behavior is impossible. Is this true? Yes, this is true. You don't have control over which nodes you connect to, so why would you need such behavior? It would only make sense if you can define a whitelist of nodes to connect to, but currently you can't do that. Your node will keep trying to connect to whatever list of peers it receives from the others, and telling them your public address itself, how is that different from allowing the peers to share it amongst themselves too? You are wrong, i can define a whitelist of nodes to connect to by firewall rules. Edit. and btw, what are nxt.pushThreshold and nxt.pullThreshold then for?
|
|
|
|
Damelon
Legendary
Offline
Activity: 1092
Merit: 1010
|
|
February 24, 2014, 11:56:21 AM |
|
little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost)
I think forging should be more interactive. For example: Someone started a node with 10000 NXT, waited for 1 week, still 10000 NXT -> Boring. plus no idea, if it actually worked or not, maybe even a false run. Other example: Someone started node with 10000, in 6 hours he get 10000.0001 Pool functionality but with no risk. There are lots of people who can run a node at work with no cost (for them ). We should show them they can earn some doing nothing. Speaking psychologically, not technically, this is completely correct.
|
|
|
|
farl4web
Legendary
Offline
Activity: 1205
Merit: 1000
|
|
February 24, 2014, 11:56:57 AM |
|
Cool! … huh Hot! shared!
|
|
|
|
marek3ball
|
|
February 24, 2014, 12:00:47 PM |
|
little hobbyists will be interested if forging every 2 to 3 days and profit must greater than cost of maintaining the node and remain immobilized the funds (oportunity cost)
I think forging should be more interactive. For example: Someone started a node with 10000 NXT, waited for 1 week, still 10000 NXT -> Boring. plus no idea, if it actually worked or not, maybe even a false run. Other example: Someone started node with 10000, in 6 hours he get 10000.0001 Pool functionality but with no risk. There are lots of people who can run a node at work with no cost (for them ). We should show them they can earn some doing nothing. I dont start bitcoin / other miner coz a lot of cooler noise. NXT makes no noise I see some connection between your idea and " Shared Forging". In case we can Share to 1000 accounts or equivalent of 1M NXT. " Shared Forging" sounds to me much more better then " Leased Forging" which leads to big pools. Today's Forging person with small NXT amount will wait 50 years to see forged block. Shared Forging person will see progress every day or week and get 0.001 NXT and not 20 NXT every 50 years. Forging / earning situation is disappointment for new people. And then they will talk bad about Nxt.
|
|
|
|
|