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 |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
A blockchain needs to be as long as longest possible fork, at least. I don't know, half a day? Definitely not 20 blocks.
Agreed - so a new "genesis" block would have to be the balance of all accounts from before the last possible "re-org" point. BTW - said "genesis" block is going to become "huge" in the future (if we had one million accounts then surely we are talking 200-300 MB which you are not very likely to be able to be sending to nodes very quickly - or are we working on some sort of special format to "compress" a genesis block?). Although it could be divisive it might also be worth "pruning" tiny balance accounts (ones with less than or equal to the minimum fee say) and having those as "fee rewards" for the construction of the new genesis block (this gives some added incentive to create it rather than just to "skip your turn" because of the "work involved"). Very interesting idea on the fees thing to prune small accounts. Do they lose their aliases too though, along with public key? But I think as long as its a network requirement for the next block to be a Genesis block then somebody will forge it. But it would be nice for a little pay off |
|
|
|
I agree with rickyjames on the blockchain pruning.
It should be done soon to test.
I guess you just need to recreate a genesis block and restart from that.
But network can't do that instantly, there will be downtime. How do we handle that?
A requirement is a machine that can do a genesis block in under a minute from an existing blockchain so it fits in with the tick-tock once per minute pattern of block forgings. Is this even remotely feasible for a say 5 MB blockchain? Discuss. I believe the way it will have to work is a network-wide rule of "every Xth block" or "blockchainsize=Y" or some other defined situation that requires the next block to be a new genesis synthesis. I believe the new genesis systhesis will have to be done for free by the forging node though. But as long as the network REQUIRES it, then at the point that the condition requires it, then all forging nodes will forget about processing new transactions and will work on forging the new genesis, and if some forging node tries to forge a block with transactions, the network will reject it. So standard forging rules for the new genesis as the next block will occur. And if a node cant keep up to perform the task (rasPI, smartphone,etc) then another node will step in, just like happens with new blocks now Will require a minute of downtime every genesis though, best case, assuming it can be done automatically, which should be possible. At least should be possible whenever the devs give up the secret to the genesis. Im all in for this testnet though, can easily generate VPSs running instances of NXT. very cool project. We can load up a smartphone and raspi with tons of testNXT so as to force them to forge more often to get an idea of their performance ETA we will not be able to use a "genesis node" for forging the new genesis, it must be a network wide rule thing that other nodes can reject new genesis if need be (to avoid centralization) |
|
|
|
<WALL O TEXT> (I did read it all)
Im with you. But genesis synthesis is not trivial, and right now is actually unknown. Will it need to be made as an automatic process, where every 500K blocks a forger must forge for free the new genesis block? I kind of think so. Then we have the problem where I dont think dev will release specifics on the genesis block, to prevent clones. Remember CfB's traps he has for clones who make their own genesis? |
|
|
|
|
CfB:
How will new cryptos that use AM on top of NXT as their blockchain deal with the periodic purges of AM transactions?
And will implementation of .01 versus .001 for fees require differing amounts of work from dev teams ?
|
|
|
|
Advanced data compression algos are helped by moores law
Same for switches, routers
Cables are problem, but maybe big breakthrough in wireless bandwidth
shannon says otherwise, and we are much closer to his comm theory limit than we are to running up on moore. thats a very large maybe in there as well |
|
|
|
How is a token generated without a key? You can always ignore accounts without a key. yes, we would need to ignore votes from accounts w/o public keys if we went the token route. but then, still people could amass an army of zombie accounts to vote their will, for just the fees of the initial transactions that created the public key If you removed the token part then it comes with the issue of the standard 1acct=1vote model of people gaming it from multiple accounts Why? There's no difference between sending nxt and generating a token. What matters is how you count a vote. dont quite follow you on this one I say: accounts are irrelevant. Even that account age won't help. 1 vote = 1 user is not good. There is nothing at stake here.
If you pay more fees, then the option u paid for should be ranked higher. Then there is something at stake.
Still IMHO.
Don't know why 1 vote = 1 user should be good.
lol new guy missed out on all our previous 'fun' |
|
|
|
Each account has a private key, which is obtained from a secret phrase, and a public key. You use private key to sign your transactions etc. Everyone can verify them using your public key. The simplest voting system would work like: a voter post his signed vote with account number. Your server gets the public key for the account and checks if it matches. If it matches the vote is counted. All votes are published at some point. Although there's no nxt api for encrypting an arbitrary message, or even getting a private key, so the key generation part would have to be reimplemented in js, or something else. EDIT: Ha! It's there. Just enter a vote in as a "website" in authorization token! Like "VOTE <voteid> YES". Everyone votes with their tokens! This is the free version of 1 account 1 vote model, except that the token is a bad idea - you can generate a token from an account w/o a public key. If you removed the token part then it comes with the issue of the standard 1acct=1vote model of people gaming it from multiple accounts |
|
|
|
I officially request that the NXTcommunityfund put out a bounty for the first person that successfully forges a block onto a simulated 300 GB NXT blockchain in a testbed setup. Full specifications of system used and documentation of experiences in accomplishing the task required to claim the reward.
If infrastructure committee does not take care of this, i will create bounty I like fee of .1 nxt for now, we can adjust again later I think marketing should shift to 100 tps and this allows raspis to be useful, let moores law keep doubling our tps. Bitcoin blockchain does not gain tps with moores law, nxt does In two years 300 gb wont seem so big Also, nxt core is such that all cool stuff, mission critical, competitor defensive, fun and quirky, everything can be developed in parallel as long as we have the resources. We now have nearly 1 million usd budget to be able to fund everything in parallel, plus as nxt gains value so does budget! These are very good developments for nxt! We are discussing seious issues and ways to improve all aspects of nxt. Everyone can contribute. I am so proud to be part of NXT!!! James holy crap. you guys realize that telco bandwidths do not follow moores law, right? at 300GB even publics nodes as SP's will choke on trying to transfer that |
|
|
|
Spamming the blockchain would actually be good, as this would give the incentive to fix the blockchain problem and allow almost unlimited transaction rates.
what do you mean blockchain problem? and setting fees based on byte-size of transactions would be the ultimate equalizer. and would untie fees from a fiat relation. Im surprised more people dont like this suggestion... Am I really that far off on this one? |
|
|
|
Fee should be as close to zero to possible because processing a transaction costs basically nothing... it's so ridiculous this is even a question. 0.000001NXT.
1000 TPS or whatever shouldn't be a problem, you only need about 32GB in theory (maximum, almost impossible case), a few MBs in practice for that. If that is a problem, just give each node 1/6 of required data (so you need 6 nodes to restore the thing) etc... but it shouldn't, ever.
Yes, but we have to be cognizant to not allow the blockchain to be spammed too cheaply via the AM or other transaction type. So lets talk about this a bit.... Firstly GUYS (and few gals we have here), we shouldn't tie the fee to try to force it to coincide with any fiat!!! At current min of 1 NXT fee for any transaction except issue asset (which isnt even possible yet) it is possible to stack up to 1000 bytes (I think) via AM, per AM transaction. Is that 1000 bytes correct? Now we could potentially just make the min fee for AM be different than for a regular transaction to prevent bloat. Now we are planning on removing AM every checkpoint/year/whatever, but what about alias? These are planned on staying forever right? Has anyone considered how much space can an alias transaction could potentially take up, between the alias string itself, and its URL? How about this... Set a min fee PER BYTE SIZE OF THE TRANSACTION IN QUESTION. And scale it up. So we can start with modeling for .001 per byte or something like that. Can some experts model for us then what the cost for certain transactions would be? Wat u guys think? |
|
|
|
I know and that might be part of the reason I go balistic on these kind of post from him especially. It feels like he is the one to decide and critize and others who get sponsored (or not) got to do all the work.
guys, lets all just take a step back for a second and take a deep breath. it looks like we are well past the point where we start to fragment. A few weeks ago we were all doing great as a team. When did it start to change? I went over to nextcoin to ask about something in the peerexplorer thread and got accused of hiding something for running my network of heavy-hallmarked VPSs. Not sure what is going wrong here.. LOL is that the real experiment? Is it really a social experiment BCNext is playing on us? LOL |
|
|
|
Some want it the way it is:
In numbers: 1.0 Count me in on that.
There are several others.
Got you for 1.0. Will repost after more to tally. Can you point me to the other 1.0s? Is a little difficult to tally when not clearly specified. (and, I really don't *want* to be responsible for tallying these votes... consolidating for review) make a google docs spreadsheet, with 4 columns: 1, .1, .01, .001 then put each username in the respective column. we all need to decided if/how community will allow 2 votes per person for different categories or let them put their 2 votes in 1 category lock it down so only you can update it, but that anyone with direct link can view it receive community's thanks for doing this work |
|
|
|
|
Show Posts
