Come-from-Beyond
Legendary
 Offline
Activity: 2142
Merit: 1010
Newbie
|
 |
January 08, 2014, 08:58:44 PM |
|
That should be easy.
Or u can use an alias that contains CRC. |
|
|
|
|
|
stdset
|
|
January 08, 2014, 09:01:41 PM |
|
That should be easy.
Or u can use an alias that contains CRC. Then you should enforce using CRCed aliases only. |
|
|
|
|
opticalcarrier
|
|
January 08, 2014, 09:02:04 PM |
|
ah. didnt realize that those went to genesis |
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 08, 2014, 09:03:38 PM |
|
That should be easy.
Or u can use an alias that contains CRC. Then you should enforce using CRCed aliases only. It's a client soft issue. |
|
|
|
|
martismartis
Legendary
Offline
Activity: 1162
Merit: 1005
|
|
January 08, 2014, 09:08:54 PM |
|
Becomes boring:
[2014-01-08 13:30:43.918] "communicationLoggingMask" = "0"
[2014-01-08 13:30:43.918] Loading transactions...
[2014-01-08 13:30:46.403] ...Done
[2014-01-08 13:30:46.404] Loading blocks...
[2014-01-08 13:30:48.561] ...Done
[2014-01-08 13:30:48.561] Scanning blockchain...
[2014-01-08 13:30:49.980] ...Done
2014-01-08 13:30:50.023:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppCo
ntext@5577d330{/,file:/D:/nxt/webapps/root/,AVAILABLE}{D:\nxt\webapps\root}
2014-01-08 13:30:50.039:INFO:oejs.ServerConnector:main: Started ServerConnector@
20bb82ca{HTTP/1.1}{0.0.0.0:7874}
2014-01-08 13:30:50.221:INFO:oejs.ServerConnector:main: Started ServerConnector@
4e54b5d4{SSL-http/1.1}{0.0.0.0:7875}
[2014-01-08 16:47:54.232] Re-scanning blockchain...
[2014-01-08 16:48:18.732] ...Done
[2014-01-08 23:01:01.653] Re-scanning blockchain...
[2014-01-08 23:01:22.350] Generated an incorrect block. Waiting for the next one
...
[2014-01-08 23:01:23.353] Generated an incorrect block. Waiting for the next one
...
[2014-01-08 23:01:24.357] Generated an incorrect block. Waiting for the next one
...
[2014-01-08 23:01:28.602] ...Done
What the hell is going on? Never had forged a block. Client 0.5.3
|
|
|
|
|
|
stdset
|
|
January 08, 2014, 09:12:42 PM |
|
That should be easy.
Or u can use an alias that contains CRC. Then you should enforce using CRCed aliases only. It's a client soft issue. This solution is ugly. 1) You will have aliases like CfB\0CFA67D9 - looks ugly 2) In another client your alias will be just CfB => people will get confused what your alias really is. 3) Some people won't use aliases at all and will continue to send money to nowhere. It's a total mess. |
|
|
|
|
salsacz
|
|
January 08, 2014, 09:16:06 PM |
|
Brainstorming
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
Nxt transfer, Alias selling and buying prohibition until a special condition met. But hackers could probably register, when the special condition happens. |
|
|
|
|
|
NxtChg
|
|
January 08, 2014, 09:27:20 PM |
|
It's a client soft issue.
Would you stop being silly? Ok, core devs, consider this very real scenario:I am building an automated payment collection API right now, similar to blockchain.info. Mostly for the exchange, but I will make it available for others too. So the merchant calls this API via URL to generate a unique address for each customer and also passes the main account number to forward money to. And now all your silly talk about how client verification is enough is shuttered into pieces, because now we have a very long and unreliable path between address source and the place where transaction is actually signed. So what happens if something goes wrong along this path? Human error, network problem, bug, glitch, anything. Bitcoin: Money isn’t forwarded. Nxtcoin: Bam! Brains all over the place. I don’t know how things are going in that perfect, illusory world of yours, where memory corruption doesn’t occur and everything’s rosy, but here in the real world, losing money is kinda big deal. So why are we playing Russian roulette with it?!
Would you kindly pull your collective head out of your collective ass and start taking this issue seriously? |
|
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 08, 2014, 09:44:33 PM |
|
Would you kindly pull your collective head out of your collective ass and start taking this issue seriously?
Well, give me an answer on a simple question: - Where CRC should be added to protect a user from sending 90000 NXT instead of 80000 NXT and how is it different from incorrect account issue? |
|
|
|
|
|
|
ferment
Full Member
Offline
Activity: 168
Merit: 100
IDEX - LIVE Real-time DEX
|
|
January 08, 2014, 09:53:50 PM |
|
It's a client soft issue.
Would you stop being silly? Why is that silly? Anyone can build on top of the NXT API and put whatever verification checks they want in a client. It would take a few days (or less) to hack together an "idiot proof" send money page that uses aliases, verifies the recipient account exists, and asks 3 times if you're really really really sure. |
|
|
|
|
chanc3r
|
|
January 08, 2014, 09:54:17 PM |
|
Anyone else had a problem with the mac-client auto-update... I get this worrying message "The hash of the downloaded update does not equal the one supplied by the blockchain. Aborting update." Which implies wherever its trying to autoupdate to 0.5.3 from it thinks the source is corrupted  |
|
|
|
msin
Legendary
Offline
Activity: 1470
Merit: 1004
|
|
January 08, 2014, 09:54:27 PM |
|
Nice work, thanks for doing that. |
|
|
|
|
|
gbeirn
|
|
January 08, 2014, 09:54:46 PM |
|
Would you kindly pull your collective head out of your collective ass and start taking this issue seriously?
Well, give me an answer on a simple question: - Where CRC should be added to protect a user from sending 90000 NXT instead of 80000 NXT and how is it different from incorrect account issue? Exactly it's a user/client side issue. |
NXT VPS Server Donations can be sent here: 6044921191674841550At the end of each month I will donate some of them back to the community. This is separate from my main wallet so you can keep track of them. I will keep them in there and only use them for hosting. |
|
|
|
wesleyh
|
|
January 08, 2014, 09:57:11 PM |
|
Anyone else had a problem with the mac-client auto-update... I get this worrying message "The hash of the downloaded update does not equal the one supplied by the blockchain. Aborting update." Which implies wherever its trying to autoupdate to 0.5.3 from it thinks the source is corrupted Hi, download 0.20 here: http://nxtra.org/macThe reason you got that message is because they're using another location for downloads now (hopefully the final time they change it..) - and what was compared was the hash of a HTML page returned at the old download location no longer in use instead of the zip. |
|
|
|
|
|
NxtChg
|
|
January 08, 2014, 09:59:07 PM |
|
- Where CRC should be added to protect a user from sending 90000 NXT instead of 80000 NXT and how is it different from incorrect account issue?
The big difference is in case of addresses you can add such checksum. So there is no reason not to. In my API example this alone is enough to solve the problem. Also, in case of the amount, the user can verify it, because it's human-readable. In case of the address - he can't notice a typo that easily. EDIT: And this is a silly talk anyway. "Let's not bother with our plane engine safety, because somebody might die of a heart attack on the plane, anyway"! |
|
|
|
|
stdset
|
|
January 08, 2014, 09:59:54 PM |
|
Would you kindly pull your collective head out of your collective ass and start taking this issue seriously?
Well, give me an answer on a simple question: - Where CRC should be added to protect a user from sending 90000 NXT instead of 80000 NXT and how is it different from incorrect account issue? Guys. Please calm down. We all want Nxt to succeed. No need for insults. I beleive we are all mature enough to be above that. Let CfB and especially Jean-Luc think about it. And, I strongly beleive, they won't be able not to fix it. In several days Jean-Luc will figure out details of the right solution, and will schedule it for implementation. There is just no other way. |
|
|
|
TwinWinNerD
Legendary
Offline
Activity: 1680
Merit: 1001
CEO Bitpanda.com
|
|
January 08, 2014, 10:03:05 PM |
|
I guess im pretty unlucky. Forging with 60k-100k for >2 weeks now, no block found...
|
|
|
|
|
notsoshifty
|
|
January 08, 2014, 10:03:35 PM |
|
But 3 GB??? That is. Just. Wrong. I also don't see why this amount of memory should be required, given the traffic volumes we're seeing now, except for buggy code. I'd (still) like to see GC logs from a JVM with >=1GB heap that runs out of memory, when using these logging parameters: -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails
Anyone can supply? |
|
|
|
|
|
