Bitcoin Forum
April 26, 2024, 05:34:28 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 [1845] 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761529 times)
starik69
Legendary
*
Offline Offline

Activity: 1367
Merit: 1000


View Profile
February 24, 2014, 10:49:27 AM
 #36881

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?  Huh
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Jean-Luc
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile WWW
February 24, 2014, 10:54:30 AM
 #36882

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?  Huh
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?


lead Nxt developer, gpg key id: 0x811D6940E1E4240C
Nxt blockchain platform | Ardor blockchain platform | Ignis ICO
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 24, 2014, 10:59:33 AM
Last edit: March 05, 2014, 08:18:54 AM by xyzzyx
 #36883

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 24, 2014, 11:03:41 AM
Last edit: February 24, 2014, 11:28:04 AM by igmaca
 #36884

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 hobbyists


I 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 Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 24, 2014, 11:05:33 AM
 #36885

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.

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

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

Activity: 421
Merit: 250


HEAT Ledger


View Profile
February 24, 2014, 11:06:10 AM
 #36886

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
February 24, 2014, 11:07:44 AM
 #36887

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
February 24, 2014, 11:10:06 AM
 #36888

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 24, 2014, 11:19:07 AM
 #36889

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
Hero Member
*****
Offline Offline

Activity: 854
Merit: 1001



View Profile
February 24, 2014, 11:22:28 AM
 #36890

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.html

I'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?


Nulli Dei, nulli Reges, solum NXT
Love your money: www.nxt.org  www.ardorplatform.org
www.nxter.org  www.nxtfoundation.org
igmaca
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 24, 2014, 11:40:28 AM
 #36891

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 Offline

Activity: 33
Merit: 0


View Profile
February 24, 2014, 11:41:07 AM
 #36892


 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 Smiley). 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  Smiley
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 24, 2014, 11:41:18 AM
 #36893

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).

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
igmaca
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 24, 2014, 11:48:22 AM
 #36894


 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 Smiley). 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  Smiley

I sincerely see the solution very easy  Grin
EmoneyRu
Hero Member
*****
Offline Offline

Activity: 600
Merit: 500

Nxt-kit developer


View Profile
February 24, 2014, 11:51:16 AM
 #36895

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 24, 2014, 11:54:03 AM
 #36896

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 Offline

Activity: 1367
Merit: 1000


View Profile
February 24, 2014, 11:55:42 AM
Last edit: February 24, 2014, 12:09:51 PM by starik69
 #36897

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?  Huh
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? Huh
Damelon
Legendary
*
Offline Offline

Activity: 1092
Merit: 1010



View Profile
February 24, 2014, 11:56:21 AM
 #36898


 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 Smiley). We should show them they can earn some doing nothing.

Speaking psychologically, not technically, this is completely correct.

Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog
farl4web
Legendary
*
Offline Offline

Activity: 1205
Merit: 1000



View Profile
February 24, 2014, 11:56:57 AM
 #36899

Green Nxt: exotic video, new version:
http://youtu.be/cP4KFH6Iz0g

feel free to share
Cool! … huh Hot!  Roll Eyes

shared!
marek3ball
Full Member
***
Offline Offline

Activity: 180
Merit: 100


View Profile
February 24, 2014, 12:00:47 PM
 #36900


 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 Smiley). 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  Smiley

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.
Pages: « 1 ... 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 [1845] 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!