xyzzyx
Sr. Member
 Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
 |
February 06, 2014, 05:33:44 AM |
|
That is, the public key would be discarded on an empty account. No?
Yup - but if when you go to create a new account you can include the public key it must use (this will require a fee to stop spamming) then it wouldn't matter if the same account with a different public key had existed before (and no way to "drain" that account). The scenario I see is more along the lines of a merchant creates one address each for payment from each of his customers. An attacker watches the blockchain for these accounts. He'll know they're there when the merchant does a sweep of them into the merchant's main account. The attacker then generates private keys that have public key's whose first 64-bits match those of the merchant's sweep accounts. When the blockchain pruning event happens, the attacker registers those new public keys. When an unaware shopper uses one, the money goes to the attacker, not the merchant. Ok, not practical now because it is too computationally expensive for *current hardware*. But it outlines a potential flaw. |
"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
|
|
|
|
|
|
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:36:41 AM |
|
Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.
Im not following, what is the signifigance of the number 44720 in regards to 1 billion? I feel dumb for not knowing, it seems like I probably should not have to ask this question  1 + 2 + 3 + ... + n = one billion. The largest so that the sum is not larger than one billion is is 44720. Therefore, there are at most 44720 different balances possible at the same time. Or 447114 for 0.01 step. <nods> Multiple accounts can have the same number of coins. |
"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
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 05:39:46 AM |
|
Holy java errors batman! root@vps1:~/nxt-kit/nxt# java -jar start.jar
WARNING: System properties and/or JVM args set. Consider using --dry-run or --exec
2014-02-06 05:38:30.341:WARN:root:main: unavailable
javax.servlet.UnavailableException: Servlet class Nxt is not a javax.servlet.Servlet
at org.eclipse.jetty.servlet.ServletHolder.checkServletType(ServletHolder.java:447)
at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:312)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:839)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:300)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
at org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:281)
at org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:213)
at org.eclipse.jetty.util.component.ContainerLifeCycle.updateBeans(ContainerLifeCycle.java:763)
at org.eclipse.jetty.server.handler.HandlerCollection.setHandlers(HandlerCollection.java:89)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.setHandlers(ContextHandlerCollection.java:144)
at org.eclipse.jetty.server.handler.HandlerCollection.addHandler(HandlerCollection.java:155)
at org.eclipse.jetty.deploy.bindings.StandardDeployer.processBinding(StandardDeployer.java:41)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:498)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:146)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:605)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:528)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:391)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:150)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:560)
at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:235)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.Server.start(Server.java:355)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
at org.eclipse.jetty.server.Server.doStart(Server.java:324)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1250)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:297)
at org.eclipse.jetty.start.Main.start(Main.java:724)
at org.eclipse.jetty.start.Main.main(Main.java:103)
2014-02-06 05:38:30.366:WARN:root:main: unavailable
javax.servlet.UnavailableException: Servlet class Nxt is not a javax.servlet.Servlet
at org.eclipse.jetty.servlet.ServletHolder.checkServletType(ServletHolder.java:447)
at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:312)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:857)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:300)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
at org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:281)
at org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:213)
at org.eclipse.jetty.util.component.ContainerLifeCycle.updateBeans(ContainerLifeCycle.java:763)
at org.eclipse.jetty.server.handler.HandlerCollection.setHandlers(HandlerCollection.java:89)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.setHandlers(ContextHandlerCollection.java:144)
at org.eclipse.jetty.server.handler.HandlerCollection.addHandler(HandlerCollection.java:155)
at org.eclipse.jetty.deploy.bindings.StandardDeployer.processBinding(StandardDeployer.java:41)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:498)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:146)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:605)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:528)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:391)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:150)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:560)
at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:235)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.Server.start(Server.java:355)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
at org.eclipse.jetty.server.Server.doStart(Server.java:324)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1250)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:297)
at org.eclipse.jetty.start.Main.start(Main.java:724)
at org.eclipse.jetty.start.Main.main(Main.java:103)
23 public hallmarked VPSs (ery heavy weights) down hard. |
|
|
|
|
|
iruu
|
|
February 06, 2014, 05:41:06 AM |
|
Holy java errors batman! 23 public hallmarked VPSs (ery heavy weights) down hard. Did you copy old web.xml from 0.5.12? They're incompatible. |
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
February 06, 2014, 05:41:09 AM |
|
Signed shift. @ M (this is an unconditional jump)
Should be @ C Don't like self-changing code. It's necessary to create subroutines. |
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:41:47 AM |
|
Holy java errors batman! [scary shit clipped] 23 public hallmarked VPSs (ery heavy weights) down hard. Hey, you might want to upgrade to 0.6.0. I think it could be bad if you don't. |
"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
|
|
|
|
pandaisftw
|
|
February 06, 2014, 05:42:36 AM |
|
That is, the public key would be discarded on an empty account. No?
Yup - but if when you go to create a new account you can include the public key it must use (this will require a fee to stop spamming) then it wouldn't matter if the same account with a different public key had existed before (and no way to "drain" that account). The scenario I see is more along the lines of a merchant creates one address each for payment from each of his customers. An attacker watches the blockchain for these accounts. He'll know they're there when the merchant does a sweep of them into the merchant's main account. The attacker then generates private keys that have public key's whose first 64-bits match those of the merchant's sweep accounts. When the blockchain pruning event happens, the attacker registers those new public keys. When an unaware shopper uses one, the money goes to the attacker, not the merchant. Ok, not practical now because it is too computationally expensive for *current hardware*. But it outlines a potential flaw. Hm, that's assuming the merchant keeps those accounts empty right? I think a workaround would be that as long as the merchant plans to use that account for his customers, it should never be empty (he asks the client to keep at least 0.01 NXT in there). If the client empties out his account, then the merchant simply generates a new one for the client to use next time and tells him to not use the old one because the client emptied it out. Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.
Im not following, what is the signifigance of the number 44720 in regards to 1 billion? I feel dumb for not knowing, it seems like I probably should not have to ask this question 1 + 2 + 3 + ... + n = one billion. The largest so that the sum is not larger than one billion is is 44720. Therefore, there are at most 44720 different balances possible at the same time. Or 447114 for 0.01 step. <nods> Multiple accounts can have the same number of coins. I think he means that there is only 447114 permutations of possible balances (at maximum). I assume this is so you can assign a certain index to a particular balance, to save space? I don't know  |
NXT: 13095091276527367030
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 05:45:30 AM |
|
Holy java errors batman! 23 public hallmarked VPSs (ery heavy weights) down hard. Did you copy old web.xml from 0.5.12? They're incompatible. yesthe first thing I checked was the good ole manual "stare and compare" All I noticed was the removal of the blockchain.nrs blurb at the beginning. I must have missed something big. |
|
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 05:47:14 AM |
|
Holy java errors batman! [scary shit clipped] 23 public hallmarked VPSs (ery heavy weights) down hard. Hey, you might want to upgrade to 0.6.0. I think it could be bad if you don't. well thats why im in this mess now, due to the upgrade to 0.6.0 Holy java errors batman! 23 public hallmarked VPSs (ery heavy weights) down hard. Did you copy old web.xml from 0.5.12? They're incompatible. yesthe first thing I checked was the good ole manual "stare and compare" of the new/old web.xml All I noticed was the removal of the blockchain.nrs blurb at the beginning I removed that but I must have missed something big. ill do it again eta: found it, was up at almost the top too. change Nxt to nxt.Nxt under servlet |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 05:47:23 AM |
|
I think he means that there is only 447114 permutations of possible balances (at maximum). I assume this is so you can assign a certain index to a particular balance, to save space? I don't know I am guessing so too - although I think it would make things rather complicated (as you would have to keep a "count" of how many accounts have that balance and then "remove" that balance when that count goes to zero, etc.). To my thinking a simple B+Tree keyed on "account id" is much easier to picture and to work with (even if it takes a lot more storage). Guess a trade-off between simplicity and size will have to be made in order to come up with an "optimal" solution. |
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 05:48:24 AM |
|
Hm, that's assuming the merchant keeps those accounts empty right? I think a workaround would be that as long as the merchant plans to use that account for his customers, it should never be empty (he asks the client to keep at least 0.01 NXT in there). If the client empties out his account, then the merchant simply generates a new one for the client to use next time and tells him to not use the old one because the client emptied it out.
I think we should seriously consider forcing this behavior so we can prune public keys of accounts with no balance and no aliases |
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:51:06 AM |
|
Hey, you might want to upgrade to 0.6.0.
I think it could be bad if you don't.
well thats why im in this mess now, due to the upgrade to 0.6.0 Ah. I can give you a copy of my blocks.nxt and transactions.nxt. You trust me?  Might want to try deleting and re-downloading the blockchain on one node. Here's a diff of web.xml: 5c5
< <servlet-class>nxt.Nxt</servlet-class>
---
> <servlet-class>Nxt</servlet-class>
9a10,14
> <param-name>blockchainStoragePath</param-name>
> <param-value>blockchain.nrs</param-value>
> </init-param>
>
> <init-param>
41c46
< <param-value>87.230.14.1; 46.19.137.116; 95.85.22.142; node18.nxtbase.com; node10.nxtbase.com; vps1.nxtcrypto.org; vps2.nxtcrypto.org; vps3.nxtcrypto.org; vps4.nxtcrypto.org; vps5.nxtcrypto.org; node16.nxtbase.com; node09.nxtbase.com; node29.nxtbase.com; 162.243.214.183; 162.243.213.115; 95.85.46.233; 162.243.140.133; 146.185.129.54; 162.243.143.15; 109.230.224.65; 54.249.101.252; 37.209.120.192; 84.112.39.24; 78.46.63.221; 69.163.47.173; 95.85.46.233; 162.243.140.133; 146.185.129.54; 162.243.117.63; 192.241.155.44; 162.243.143.15; 93.190.92.74; 37.209.120.192; 93.190.92.75; 85.25.134.59; 93.190.92.76; nxtwallet.com; nxt.ddos.me; 203.174.12.25; 88.198.142.92; 66.197.138.90; 64.120.180.106; 109.230.224.65; 80.86.92.50; node1.nextcoin.it; node2.nextcoin.it; node3.nextcoin.it; node4.nextcoin.it; node5.nextcoin.it; nxt.homer.ru; 31.204.130.123; 209.222.0.194; 209.222.16.10;</param-value>
---
> <param-value>87.230.14.1; 46.19.137.116; 95.85.22.142; node18.nxtbase.com; node10.nxtbase.com; vps1.nxtcrypto.org; vps2.nxtcrypto.org; vps3.nxtcrypto.org; vps4.nxtcrypto.org; vps5.nxtcrypto.org; node16.nxtbase.com; node09.nxtbase.com; node29.nxtbase.com; 162.243.214.183; 162.243.213.115; 95.85.46.233; 162.243.140.133; 146.185.129.54; 162.243.143.15; 109.230.224.65; 54.249.101.252; 37.209.120.192; 84.112.39.24; 78.46.63.221; 69.163.47.173; 95.85.46.233; 162.243.140.133; 146.185.129.54; 162.243.117.63; 192.241.155.44; 162.243.214.68; 95.85.46.164; 162.243.216.55; 162.243.143.15; 95.85.46.249; 93.190.92.74; 37.209.120.192; 93.190.92.75; 85.25.134.59; 93.190.92.76; nxtwallet.com; 31.220.50.208; nxt.ddos.me; 203.174.12.25; 88.198.142.92; 66.197.138.90; 64.120.180.106; 109.230.224.65; 80.86.92.50; node1.nextcoin.it; node2.nextcoin.it; node3.nextcoin.it; node4.nextcoin.it; node5.nextcoin.it; nxt.homer.ru; 31.204.130.123; 209.222.0.194; 209.222.16.10;</param-value>
|
"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
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 06:00:58 AM
Last edit: February 06, 2014, 06:13:20 AM by xyzzyx |
|
Hm, that's assuming the merchant keeps those accounts empty right? I think a workaround would be that as long as the merchant plans to use that account for his customers, it should never be empty (he asks the client to keep at least 0.01 NXT in there). If the client empties out his account, then the merchant simply generates a new one for the client to use next time and tells him to not use the old one because the client emptied it out.
The merchant one was just an example of one possible attack. I wouldn't be surprised if there were many others. Speaking of attack, I'm very disappointed in Emule. I guess it's time to cancel my 0.00005 buy order and move it up.  |
"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
|
|
|
^[GS]^
Member
Offline
Activity: 112
Merit: 10
|
|
February 06, 2014, 06:17:29 AM |
|
fix me! only 1 to 0.1! I never said 0.3333  0.3333 is only meant to as way to divide your vote by 3. So, you have 1/3 vote in 0.01, 0.1, and 1 columns. Analysis based upon your post here: I vote 0.1 Fee for transactions!
and 0.01 for messages! 1 NXT for alias.
If this is not desired, please specify how this should be tallied. Sorry for the confusion. In general fee, 0.1 is fine! I just wanted to describe various fee in different functions. Holy java errors batman! 23 public hallmarked VPSs (ery heavy weights) down hard. Did you copy old web.xml from 0.5.12? They're incompatible. which is what is new in web.xml from 0.6.0? PS: API would be very useful to reload web.xml while running. besides being able to read the hallmark of oneself from admin.html. |
|
|
|
|
|
pandaisftw
|
|
February 06, 2014, 06:25:28 AM |
|
Hm, that's assuming the merchant keeps those accounts empty right? I think a workaround would be that as long as the merchant plans to use that account for his customers, it should never be empty (he asks the client to keep at least 0.01 NXT in there). If the client empties out his account, then the merchant simply generates a new one for the client to use next time and tells him to not use the old one because the client emptied it out.
I think we should seriously consider forcing this behavior so we can prune public keys of accounts with no balance and no aliases Speaking of aliases, another way to "preserve" your account would be simply registering an alias. You have to send out a transaction anyways to get your public key, so if you're interested in making some "back-up" empty accounts, you just register an alias as you would have anyways. In the merchant example, the merchant simply just makes up an alias for the customer (maybe an ID #) on that account, and the account won't be erased during pruning. |
NXT: 13095091276527367030
|
|
|
^[GS]^
Member
Offline
Activity: 112
Merit: 10
|
|
February 06, 2014, 06:31:34 AM |
|
Found in "Get Peers" of https://localhost:7875/admin.html"184.75.214.66",
"36.63.156.102",
"adress_ip", <<<
"188.27.102.67",
"108.53.130.113", "95.85.46.126",
"84.6.140.192",
"50.30.46.177;209.126.96.136;209.126.96.137;209.126.96.138", <<<
"195.3.205.202",
"109.75.223.181", Perhaps should better control of peers. It could even prevent connecting to very old versions. |
|
|
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 06:50:47 AM
Last edit: February 06, 2014, 07:01:02 AM by xyzzyx |
|
I don't think a low-memory device like a RaspberryPi would need a full blockchain to forge. It would only need just over 1440 blocks. If it needs to consult blocks that it doesn't have because they're too far in the past, it can get them by querring the API of a public node -- or several public nodes.
It can keep a list of SHA256 hashes of the blocks it deletes to check that the ones it gets from a public node are correct.
Or am I missing something?
|
"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
|
|
|
lucky88888
Sr. Member
Offline
Activity: 404
Merit: 250
https://nxtforum.org/
|
|
February 06, 2014, 07:04:19 AM |
|
To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him. But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.
Most Nxt users are not "developers", so while I take your point, I also suggest that most people are being asked to update software without being able to understand OR verify the reason for the update. It's the software-developer equivalent of "trust me. Just do it." It's hypocritical to build a decentralized system that is supposed to be trustless, and then ask "untrusted" members of that community to "trust" that they should install new software and not ask questions of the "untrusted" people who issue the order. You can do your own thing, of course, but I won't give. I'm not gonna jump off a bridge just because Jean-Luc or CfB says so. What they've done is bad, and they should feel bad. When I get an explanation, I'll update my software. It is unfortunate they had to do it this way, but if they said it was urgent, then it most likely is. The fact that both of them (and I suppose the implicit approval of BCNext) approved it makes it not as bad. C-f-b did say he would disclose what it was, but I'm sure how won't do that until a large majority of nodes have upgraded to 0.6.0. While its possible for someone to secretly add something inside for his own selfish need BUT in this case, its Jean-Luc and CfB for crying out loud.. im sure they would not try to do anything that is bad for nxt, it would be in their best interest to do what is right. If they don't the whole eco would collapse over night. They are the lead devs, from what i know they are probably the only ones coding nxt for what it is today. If you won't trust the only core developers, i don't know who else is there to trust in such situation. I'm pretty damn sure they are pushing this update for one reason, that is to prevent exploitation of the said critical bug. And to me, it sounds pretty serious when they are not saying the specifics of the actual bug, maybe they are hoping for majority to update and be on the 0.6.0 chain before such bug is exploited thus not providing such details. To sum up: ITS SAFE TO UPDATE to 0.6.0 so please everyone upgrade as soon as possible before someone finds such exploit mentioned. CRITICAL MANDATORY UPDATEhttp://download.nxtcrypto.org/nxt-client-0.6.0.zip |
Fuck Mt.Gox! Fuck Mintpal! Fuck Bter! FUCK kyc! Protect yourself use MGW! SUPERNET! Recommended ASSET ->InstantDex : Lead Dev Jl777 (decentralized multi currency instant exchange) Recommended ASSET -> Jinn : Lead Dev Come-from-Beyond (ternary processors!) https://nxtforum.org/news-and-announcements/(ann)-jinn/ |
|
|
farl4web
Legendary
Offline
Activity: 1205
Merit: 1000
|
|
February 06, 2014, 07:11:35 AM |
|
Tonight I was thinking again about the fees. We should not change the fees already, it's not wise.
In this early fase of Nxt I hear nobody complaining about the high fees, mostly because not a lot of payments are done.
But I DO hear a lot of complaining about the joke of forging. In the early fase of a cryptocoin, the miners/investors are the most important people, they make a coins succesfull (look at Dogecoin). To get a lot of attention, we need to attract the miners and investors first!
Later when it gets more populair you can lower the fees!
|
|
|
|
|
|
