|
281
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 26, 2014, 03:26:37 PM
|
who can refute my idea?
Try writing your idea in math or in a simulator rather than just trying to ask people to "refute" it. how many accounts are you running in each simulation instance? Just a few will not cut it and is not a good representation of how TF works in the wild. See the source code transparent forging thread, I believe it was, for more info on this. You need to model as many accounts as possible, I would say at least 100 per simulation run. |
|
|
|
|
282
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 26, 2014, 03:23:06 PM
|
Alright so i need a little help understanding something. I have two servers running on two separate computers. Both servers have the same account unlocked. I know the answer is going to be no, but i just want to understand how and why.. Does this double my chances of forging a block?
it doesnt, and in fact I believe CfB has stated in the past that this is a very bad practice, for reasons I cant understand though. does anyone know why this is bad? And if its so bad, what do we need to work on to mitigate the threat? Yeah id love to see the reasoning. Im hoping we can get some insight. Thank you for the reply, ill stick to just one server then. It doesn't double the chance to forge a block, but when you do forge a block, you will do it twice and thus, you are creating a fork. This seems to be a serious attack possibility. what happens if a whale or pool operator goes rogue and starts forging from 100 different public VPSs? |
|
|
|
|
284
|
Alternate cryptocurrencies / Altcoin Discussion / Re: [Nxt] API of Nxt
|
on: February 26, 2014, 02:54:39 PM
|
API, Latency and batch mode:
I've been rewriting my client to do client-side signing and connect to a random public node and I am now running into latency problems.
E.g. for showing a detailed list of peers I need to call getPeers and the cycle over all returned peers and call getPeer&peer=PEERNAME.
For long running public nodes like nodeX1.nxtbase.com getPeers returns 1000, 2000 or more peers and my client has to do that many back and fourth requests. This was no problem when running NRS locally, but it is a problem with remote hosts.
This might not be a a huge problem for peers (I could simply drop the peer list in my client), but it will be a problem for getting account transactions, asset trades and asset orders. This will simply not scale.
Proposal:
Offer batch mode API calls, e.g.:
getPeersDetail returning
{"peers":
[{"shareAddress":true,"platform":"PC","application":"NRS","weight":0,"state":2,"announcedAddress":"199.217.117.152","downloadedVolume":379,"version":"0.7.3","uploadedVolume":12647},
...
]
}
For peers it might make sense to add a filter option like "state=1" to only get the connected peers.
Similiar batch calls would make sense for getting account transactions, orders and trades, probably together with startIndex/endIndex or startDate/endDate where applicable.
yes, I concur with the &state=1 modification to the getPeers API. IF only to support light-clients. |
|
|
|
|
285
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 25, 2014, 10:25:27 PM
|
Alright so i need a little help understanding something. I have two servers running on two separate computers. Both servers have the same account unlocked. I know the answer is going to be no, but i just want to understand how and why.. Does this double my chances of forging a block?
it doesnt, and in fact I believe CfB has stated in the past that this is a very bad practice, for reasons I cant understand though. does anyone know why this is bad? And if its so bad, what do we need to work on to mitigate the threat? |
|
|
|
|
288
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information 0.8.1e on raspi
|
on: February 25, 2014, 02:32:12 PM
|
I seem to have some config param missing in my raspi - when I start 0.8.1e using: java -Xmx128M -Xmx480M -cp nxt.jar:lib/*:conf nxt.Nxt
most of the startup process incl. starting blockachin seems to go well, but it crashes when launching the ui server:
[2014-02-25 10:05:15.203] shareMyAddress is disabled, will not start peer networking server
[2014-02-25 10:05:15.289] nxt.allowedBotHosts = "127.0.0.1; localhost; 192.168.178:25; 192.168.178.26; 0:0:0:0:0:0:0:1;"
[2014-02-25 10:05:15.300] nxt.enableAPIServer = "true"
[2014-02-25 10:05:15.304] nxt.apiServerPort = "7876"
[2014-02-25 10:05:15.312] nxt.apiServerHost = "127.0.0.1"
[2014-02-25 10:05:15.701] nxt.apiSSL = "false"
[2014-02-25 10:05:15.976] nxt.apiServerIdleTimeout = "30000"
[2014-02-25 10:05:16.002] nxt.apiResourceBase = "html/tools"
[2014-02-25 10:05:16.318] nxt.javadocResourceBase = "html/doc"
[2014-02-25 10:05:16.727] nxt.apiServerCORS = "false"
[2014-02-25 10:05:16.814] nxt.allowedUserHosts = "127.0.0.1; localhost; 0:0:0:0:0:0:0:1;"
[2014-02-25 10:05:16.820] nxt.enableUIServer = "true"
[2014-02-25 10:05:16.825] nxt.uiServerPort = "7875"
[2014-02-25 10:05:16.833] nxt.uiServerHost = "127.0.0.1; 0.0.0.0"
[2014-02-25 10:05:16.838] nxt.uiSSL = "false"
[2014-02-25 10:05:16.846] nxt.uiServerIdleTimeout = "30000"
[2014-02-25 10:05:16.851] nxt.uiResourceBase = "html/nrs"
[2014-02-25 10:05:16.857] nxt.javadocResourceBase = "html/doc"
[2014-02-25 10:05:16.870] nxt.uiServerCORS = "false"
[2014-02-25 10:05:17.123] Genesis block already in database
[2014-02-25 10:05:17.129] Scanning blockchain...
[2014-02-25 10:05:30.649] ...done
[2014-02-25 10:05:31.182] Started API server at 127.0.0.1:7876
[2014-02-25 10:05:31.306] DEBUG: Failed to start user interface server
However, on my regular workstation 0.8.1e starts without trouble:
[2014-02-25 09:34:35.931] Genesis block already in database
[2014-02-25 09:34:35.931] Scanning blockchain...
[2014-02-25 09:34:47.923] ...done
[2014-02-25 09:34:48.063] Started peer networking server at 0.0.0.0:7874
[2014-02-25 09:34:48.066] Started API server at 127.0.0.1:7876
[2014-02-25 09:34:48.095] Started user interface server at 127.0.0.1:7875
[2014-02-25 09:34:48.098] Nxt server 0.8.1e started successfully.
[2014-02-25 09:41:59.910] nxt.apiServerEnforcePOST = "false"
What setting did I miss?
the console gives a stacktrace:
java.net.SocketException: Unresolved address
at sun.nio.ch.Net.translateToSocketException(Net.java:157)
at sun.nio.ch.Net.translateException(Net.java:183)
at sun.nio.ch.Net.translateException(Net.java:189)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:76)
at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:279)
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:218)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at org.eclipse.jetty.server.Server.doStart(Server.java:336)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
at nxt.user.Users$1.run(Users.java:153)
at nxt.util.ThreadPool.start(ThreadPool.java:38)
at nxt.Nxt$Init.<clinit>(Nxt.java:187)
at nxt.Nxt.init(Nxt.java:156)
at nxt.Nxt.main(Nxt.java:147)
Caused by: java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:127)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:208)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
... 11 more
nxt.allowedBotHosts = "127.0.0.1; localhost; 192.168.178:25; 192.168.178.26; 0:0:0 get rid of thta :25? |
|
|
|
|
290
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 25, 2014, 02:46:02 AM
|
OK, now that we can use POST instead of GET on 0.8.1e, can someone tell me whats wrong here? $ curl -sk --data "requestType=getBalance&account=6666386410" https://localhost:7876
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 405 </title>
</head>
<body>
<h2>HTTP ERROR: 405</h2>
<p>Problem accessing /. Reason:
<pre> HTTP method POST is not supported by this URL</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>
</body>
</html>
$
|
|
|
|
|
291
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 25, 2014, 02:23:33 AM
|
Throwing out some suggestions here on prevention of centralization due to leased forging power...
Set a hard limit on size of a pool's effectiveBalance consisting of leased power. Maybe 5M or 10M NXT or something like that? We may even want to set a limit to max size of a single account's effectiveBalance, such that if a single account's balance is higher than, say, 10M NXT, then its effectiveBalance is limited to 10M. Users could then choose to split accounts and forge on different machines that would then provide a measure of redundancy.
Since I have some real world stuff to do, I don't have time to read every post about the discussion right now, sorry if this has already been discussed. but setting a hard limit cannot prevent the centralization. Since it is his business, the pool operator will just create as many as necessary accounts using as pools and forge on one computer. you didnt quote the second part of my post And since these countermeasures *could* be broken via configurations of software/hardware if the pool operator or user *really* wanted to, I think we still should pursue the TF option of selecting secondary, tertiary and even 4th and 5th accounts that could quickly forge a block should higher priority accounts fail to forge in a quick manner.
The goal isnt necessarily to prevent someone forging with a ton of NXT from forging blocks - its to split up resources as much as possible to guard against a large pool experiencing issues when it is its time to forge a block. So we make a max size to force processes to be split up so that if there is a failure of a process, they all dont die. Now this wont necessarily prevent a hardware failure from causing this issue though. But a proper pool operator would probably want to build redundancy anyways - to maximize forging profits. Having 3/4/5 forging backups in the protocol is just more redundancy. But maybe the REAL key here to prevent forging centralization in the first place is to make forging as an end UNPROFITABLE. We should start looking into things with a cause/effect outlook. Visualize our desired ideal scenario of a well-distributed network of forgers. Go through different actions (current state, proposedChangeA, proposedChangeB, etc) and try to determine the effects. What actions should we take now to prevent centralization in the future? Can those actions have any other adverse effects? Eventually we will come to the appropriate course |
|
|
|
|
298
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 24, 2014, 05:52:37 PM
|
To summarize: For users with dynamic IPs, you ... still need to set up port forwarding at your router.
Has this always been the case? Or is this the case since a specific version? What does or does not happen if we don't set up port forwarding? Having an internal DHCP network behind the dynamic WAN IP address, how can we set up port forwarding  Or does the server has to run on an internal fixed IP address then It confuses me. May be I lack some IP networking knowledge. Please, elaborate? thats what he says, but I believe that he means that if your intent is to run a public node then you need the port forward on your WAN router. Im using 0.8.1e at home, with sharmyaddress set to false, and dont have a port forwarded, am even using tor, and Im still getting updated blocks from peers. |
|
|
|
|
299
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: NXT :: descendant of Bitcoin - Updated Information
|
on: February 24, 2014, 03:55:22 PM
|
|
Throwing out some suggestions here on prevention of centralization due to leased forging power...
Set a hard limit on size of a pool's effectiveBalance consisting of leased power. Maybe 5M or 10M NXT or something like that? We may even want to set a limit to max size of a single account's effectiveBalance, such that if a single account's balance is higher than, say, 10M NXT, then its effectiveBalance is limited to 10M. Users could then choose to split accounts and forge on different machines that would then provide a measure of redundancy.
And since these countermeasures *could* be broken via configurations of software/hardware if the pool operator or user *really* wanted to, I think we still should pursue the TF option of selecting secondary, tertiary and even 4th and 5th accounts that could quickly forge a block should higher priority accounts fail to forge in a quick manner.
|
|
|
|
|
300
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN PoS+ PoW] eXocoin [EXO] - gen 2.0 - developed from scratch! Free Give-Away
|
on: February 24, 2014, 02:54:43 PM
|
It isn't clear to me whether, or until when, first-stage investors can pull out for a full refund. Has this been clarified by the dev (for any case other than the project completely failing to launch)?
If you are with escrow you can pull out even just one day before the launch It's still your money if it is in the hands of an escrow  Can dev and/or Anon136 confirm whether use of escrow gives me some get-out option, even if dev delivers 100% on his promise? It does. You may opt out for any reason you wish or even with out any reason at all. However i will not speak to the morality of backing out even if he delivers on all of his promises, that's for you to decide. did terms of escrow as described by OP allow for pulling out? I would think that unless specific terms were in there allowing bailing out, that a REAL escrow service would hold the funds until "eXo was sent", then would disburse the BTC to OP. This is the definition of escrow. And when I use the term "eXo was sent" I would expect eXo to be sent directly to purchaser, not through escrow service, since escrow service can check blockchain to see that eXo was sent. Also by the term "eXo was received" the eXo I refer to BETTER had some advanced features available to make sure we can tell the eXo product isnt just some closed source clone of existing coin. |
|
|
|
|
Show Posts
<3
