Author

Topic: NXT :: descendant of Bitcoin - Updated Information - page 1051. (Read 2761642 times)

full member
Activity: 224
Merit: 100
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.

Quote
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  Embarrassed
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.  


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 Grin
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.

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.
legendary
Activity: 2142
Merit: 1010
Newbie

Signed shift.

Quote
@ M (this is an unconditional jump)
Should be
@ C
Don't like self-changing code.

It's necessary to create subroutines.
full member
Activity: 148
Merit: 100

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.
full member
Activity: 238
Merit: 100

Holy java errors batman!

Code:
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.
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
Quote
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  Embarrassed
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.  


Multiple accounts can have the same number of coins.
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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.
full member
Activity: 148
Merit: 100
Quote
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  Embarrassed
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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).
hero member
Activity: 600
Merit: 500
Nxt-kit developer
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.
 Cheesy

Useless pop-up. 1 unneeded click
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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?
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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.
full member
Activity: 238
Merit: 100
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
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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.

legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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?).
full member
Activity: 238
Merit: 100
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
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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?
full member
Activity: 238
Merit: 100
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
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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
Jump to: