Bitcoin Forum
July 19, 2019, 09:58:31 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 [1511] 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2755393 times)
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:13:46 AM
 #30201

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

Posts: 1563573511

View Profile Personal Message (Offline)

Ignore
1563573511
Reply with quote  #2

1563573511
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563573511
Hero Member
*
Offline Offline

Posts: 1563573511

View Profile Personal Message (Offline)

Ignore
1563573511
Reply with quote  #2

1563573511
Report to moderator
1563573511
Hero Member
*
Offline Offline

Posts: 1563573511

View Profile Personal Message (Offline)

Ignore
1563573511
Reply with quote  #2

1563573511
Report to moderator
1563573511
Hero Member
*
Offline Offline

Posts: 1563573511

View Profile Personal Message (Offline)

Ignore
1563573511
Reply with quote  #2

1563573511
Report to moderator
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 06, 2014, 05:17:12 AM
 #30202

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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:19:55 AM
 #30203

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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:21:41 AM
 #30204

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

Activity: 600
Merit: 500

Nxt-kit developer


View Profile
February 06, 2014, 05:25:13 AM
 #30205

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

CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 06, 2014, 05:26:59 AM
 #30206

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

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

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

Activity: 148
Merit: 100


View Profile
February 06, 2014, 05:28:14 AM
Last edit: February 06, 2014, 05:39:28 AM by iruu
 #30207

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.

xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:33:44 AM
 #30208

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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:36:41 AM
 #30209

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.  

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

Activity: 238
Merit: 100



View Profile
February 06, 2014, 05:39:46 AM
 #30210


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

Activity: 148
Merit: 100


View Profile
February 06, 2014, 05:41:06 AM
 #30211


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 Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
February 06, 2014, 05:41:09 AM
 #30212


Signed shift.

Quote
@ 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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:41:47 AM
 #30213


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

Activity: 224
Merit: 100


View Profile
February 06, 2014, 05:42:36 AM
 #30214

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.  

<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 Grin

NXT: 13095091276527367030
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 06, 2014, 05:45:30 AM
 #30215


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

Activity: 238
Merit: 100



View Profile
February 06, 2014, 05:47:14 AM
 #30216


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 Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 06, 2014, 05:47:23 AM
 #30217

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

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.

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

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

Activity: 238
Merit: 100



View Profile
February 06, 2014, 05:48:24 AM
 #30218

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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 05:51:06 AM
 #30219

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

Might want to try deleting and re-downloading the blockchain on one node.

Here's a diff of web.xml:

Code:
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 Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 06:00:58 AM
Last edit: February 06, 2014, 06:13:20 AM by xyzzyx
 #30220

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

"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
Pages: « 1 ... 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 [1511] 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 ... 2567 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!