M
MangledBlue
Guest
Most MNs are setup with Static IP addresses but there are a few that use a, dynamic IP, namely individuals that run their MN(s) from home, at the moment.
ISPs, generally, only give a static IP address to business accounts but residential accounts, if allowed, must purchase a static IP address. Now, even tho a residential IP address is considered to be dynamic, I have found that they, the IP addreeses given out by ISPs and are considered to be dynamic, act more like a static IP over time. I personally, have been able to run my Pi(s) from a residential, dynamic IP for over a year. The only time the IP address actually changes, is when I swap out the modem, at least, so far.
Even with that said, why should we limit MNs to any static IP?
Why couldn't the MNs be coded in such a way to allow for a TRUELY dynamic IP address? - like say, a Cell phone that does in fact have a true dynamic IP that changes often but in no particular "pattern" and/or time frame. This generally occurs when switching from cell tower to cell tower, I do believe, and during times of lag by the user from non-usage for "X length of time"
Right now, the MNs, being a two part/piece entity [Hot and Cold sides] seem to "sync" up with each other. Meaning that, you cannot start a MN without either side of the [Hot and Cold] wallets being "activated". Sure you could do a Hot MN but nobody should risk it, for any reason.
Why not get the Cold side to check it's IP address every 15 minutes or so and if it does change, the MN could/would "rewrite" the masternode.conf and/or dash.conf file to correct the new IP the Cold side is on, then reboot to activate the correct IP. The 15 minute, IP check time, might actually need to be lower than 15 minutes to accommodate all devices and IP carriers but once the IP address has been up-dated, with the said *.conf file(s), the MN, on the cold side, the MN would reboot it's self so the entire MN system would/could recognize the MN IP has changed. BUT - as I have recently learned - The IP address does not actually up-date on the whole MN system, unless the MN "drops" off the current MN list. This of course causes the MN to still get paid but the MN does not actually perform any "function". This also returns to the MN to the "end of the line" of any MN payment to be had.
Now the system could be ?? "gamed" ?? and/or an attack vector could be possible ?? by allowing dynamic IPs to work like this BUT the system could check all other MN IPs and if it is found that the IP address the MN is trying to use is already in use, the 2nd and/or "duplicate" IP address would not be allow on the MN system. BUT - I'm sure that I'm also over-looking "other" possible attack vectors.
During the initial MN "sync", the MNs would need to "pair" up by signing the cold and hot side(s) but would not be required to maintain, said sync. The hot side would be allowed to be on any IP at any time but the cold side, which is the portion of the MN pair that actually preforms the "function(s)/services" of the MN would be required to up-date it's self and reboot, correcting the IP dependency......
I know that this post is not being written with all possibilities included and I have no idea how to code. I would hope that it does spark the interest of somebody/anybody willing to give it a try, to say the least.
Run with it if you want/can....
edit for spelling
ISPs, generally, only give a static IP address to business accounts but residential accounts, if allowed, must purchase a static IP address. Now, even tho a residential IP address is considered to be dynamic, I have found that they, the IP addreeses given out by ISPs and are considered to be dynamic, act more like a static IP over time. I personally, have been able to run my Pi(s) from a residential, dynamic IP for over a year. The only time the IP address actually changes, is when I swap out the modem, at least, so far.
Even with that said, why should we limit MNs to any static IP?
Why couldn't the MNs be coded in such a way to allow for a TRUELY dynamic IP address? - like say, a Cell phone that does in fact have a true dynamic IP that changes often but in no particular "pattern" and/or time frame. This generally occurs when switching from cell tower to cell tower, I do believe, and during times of lag by the user from non-usage for "X length of time"
Right now, the MNs, being a two part/piece entity [Hot and Cold sides] seem to "sync" up with each other. Meaning that, you cannot start a MN without either side of the [Hot and Cold] wallets being "activated". Sure you could do a Hot MN but nobody should risk it, for any reason.
Why not get the Cold side to check it's IP address every 15 minutes or so and if it does change, the MN could/would "rewrite" the masternode.conf and/or dash.conf file to correct the new IP the Cold side is on, then reboot to activate the correct IP. The 15 minute, IP check time, might actually need to be lower than 15 minutes to accommodate all devices and IP carriers but once the IP address has been up-dated, with the said *.conf file(s), the MN, on the cold side, the MN would reboot it's self so the entire MN system would/could recognize the MN IP has changed. BUT - as I have recently learned - The IP address does not actually up-date on the whole MN system, unless the MN "drops" off the current MN list. This of course causes the MN to still get paid but the MN does not actually perform any "function". This also returns to the MN to the "end of the line" of any MN payment to be had.
Now the system could be ?? "gamed" ?? and/or an attack vector could be possible ?? by allowing dynamic IPs to work like this BUT the system could check all other MN IPs and if it is found that the IP address the MN is trying to use is already in use, the 2nd and/or "duplicate" IP address would not be allow on the MN system. BUT - I'm sure that I'm also over-looking "other" possible attack vectors.
During the initial MN "sync", the MNs would need to "pair" up by signing the cold and hot side(s) but would not be required to maintain, said sync. The hot side would be allowed to be on any IP at any time but the cold side, which is the portion of the MN pair that actually preforms the "function(s)/services" of the MN would be required to up-date it's self and reboot, correcting the IP dependency......
I know that this post is not being written with all possibilities included and I have no idea how to code. I would hope that it does spark the interest of somebody/anybody willing to give it a try, to say the least.
Run with it if you want/can....
edit for spelling
Last edited:
