|
lyynx
|
 |
February 06, 2014, 05:01:16 AM |
|
Has anyone been having issues since 5.12? I have been generating a ton of bad blocks since 5.11 and 5.12 . As of today, it has been out of control.
|
|
|
|
Zahlen
Member
 Offline
Activity: 98
Merit: 10
|
|
February 06, 2014, 05:01:55 AM |
|
+2. Good post Zahlen. Better PM him in case he's stopped reading this thread.
Thanks, I did  Well, there goes my "work on Nxt" time for today. Becoming a trend lately  |
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 05:02:24 AM
Last edit: February 06, 2014, 05:13:52 AM by opticalcarrier |
|
Regarding just purging accounts, what about when the value of .99NXT is extremely high, as we do expect it to? Or if an account with only .01 NXT in it has many aliases? Then I dont think this would be feasable and I think we must design for the worst case of .01 NXT (or .001 or .0001 or whatever we go with) in many accounts, and write a new genesis block with public keys coupled with balances and aliases, coded in binary format. Obviously we would completely purge any public keys for accounts with zero balance and with no aliases. At a minimum you would need to store the account # (64 bits) plus the public key (256 bits) plus the balance (64 bits?) which would be 384 bits or 48 bytes per account. Account id is a sha of public key. It doesn't need to be stored, except as an optimization. Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances. thanks Ciyam for doing that math, I was away from home reading on my phone and was gearing up to do it myself when I got back 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  EDIT: wait i figured it out, you are trying to save space on storing balances. i r not completely dumb Obviously we would purge |
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:04:23 AM |
|
Has anyone been having issues since 5.12? I have been generating a ton of bad blocks since 5.11 and 5.12 . As of today, it has been out of control.
Upgrade to 0.6.0, please. http://wiki.nxtcrypto.org/wiki/Nxt_Software |
"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:07:26 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. must be something really bad like a zero day |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1111
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 05:07:53 AM |
|
But that's what I wrote.
Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory? |
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:10:16 AM |
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? Merchants may generate a unique address for each patron. Once the public keys are discarded, how easy would it be for an attacker to generate one for that address? |
"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:11:15 AM |
|
And somebody please tell me how you booby trap a genesis block so we've got to wait for source code release to start on this?
There's no need for this. A balance sheet is the exact same thing as blockchain, just in a different form. It doesn't matter what supposed traps are in a genesis block. It's not a problem. There's one big problem, a "referenced transaction". Currently you can send a transaction which is valid only if referenced transaction is valid. That's fundamentally incompatible with limited blockchain. So either the 'referenced transaction' is limited to 'transaction in the last n blocks' or it goes entirely. other big problem is effectiveBalance vs balance and previous transactions not having 1440 confirmations |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1111
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 05:12:54 AM |
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?). |
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:13:46 AM |
|
other big problem is effectiveBalance vs balance and previous transactions not having 1440 confirmations
I don't think this will be a problem. You would still have the most recent 1440+ blocks. |
"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:17:12 AM |
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?). no i think hes right, and i was wrong. you didnt quote his edit to add the blurb about merchants storing old accounts. things could get very hairy and mixed up that way.. kinda dangerous the more I think about it, to completely purge. wed have to well publicize the risk would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out. Wed either have to track that as well or just make it kick back to account owner upon pruning |
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 05:19:55 AM |
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?). no i think hes right, and i was wrong. you didnt quote his edit to add the blurb about merchants storing old accounts. things could get very hairy and mixed up that way.. kinda dangerous the more I think about it, to completely purge. wed have to well publicize the risk They may not be able to do it *right now*, but in a few years it may become feasible. From the attacker's point of view it's the same problem to solve as darkNXT mining. |
"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, 05:21:41 AM |
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?). Would the account with a zero balance and a full public key survive the blockchain pruning event? Perhaps I'm not understanding fully, but it looks to me that it wouldn't. That is, the public key would be discarded on an empty account. No? |
"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
|
|
|
|
EmoneyRu
|
|
February 06, 2014, 05:25:13 AM |
|
More fun updates on my installer...a picture say it all: It now checks the SHA-256 of the Nxt-Client-0-x-x.zip file BEFORE it is extracted and installed. If it fails, setup is forced to exit. Still have some work to do, but the proof of concept is there and working.  Useless pop-up. 1 unneeded click |
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1111
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 05:26:59 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). |
|
|
|
|
iruu
|
|
February 06, 2014, 05:28:14 AM
Last edit: February 06, 2014, 05:39:28 AM by iruu |
|
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 n so that the sum is not larger than one billion is 44720. Therefore, there are at most 44720 different balances possible at the same time. Or 447114 for 0.01 step. Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory?
I'm not sure what you're asking here. What is an 'index node'? I have an array of pairs (public key, balance index), and I sort them by first 64 bit of public key's sha256, which is an account id. If I want to find account's public key and balance I binary search for it in this sorted array, which gives me public key and balance index. Balance index is an index into an array of all currently existing balances. no i think hes right, and i was wrong. you didnt quote his edit to add the blurb about merchants storing old accounts. things could get very hairy and mixed up that way.. kinda dangerous the more I think about it, to completely purge. wed have to well publicize the risk
would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out. Wed either have to track that as well or just make it kick back to account owner upon pruning
Accounts should be 256 bit public keys and that's it. 64 bit account numbers are a complete idiocy. The only way to both have a secure system and finite blockchain is to make accounts 256 bit, with extra code for backward compatibility with current accounts. Which is obviously not going to happen. |
|
|
|
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
|
|
|
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. |
|
|
|
|
