I read that earlier today. did you read that? it was arbitrary, no math behind it. It Should be Observed That this probability does not out stretch to 0 (asm! 1) if the bad guy has at Least 1 = 3 of all active balances in the network in the case of U-algorithm (corresondingly, At Least 1 = 2 in the case of exp-algorithm). There should exist some speci fic methods for protecting network against Such an attack in the CASE WHEN there is risk that (active) relative balance of the bad guy Could Become larger than the above threshold
it may be a good idea to limit the forging power of accounts by some fixed threshold, e.g., if an account has more than, say, 300K NXT,then it forges as if it had exactly 300K NXT. Of course, a rich guy can split his fortune between smaller accounts, but then all those accounts would forge roughly as one big account (without threshold) under Exp-algorithm. One can one use the computationally easier U-algorithm without having the drawbacks discussed in this section. how to interpret the 1 = 3 and 1 = 2 parts? Nevermind, from the paper, its 1/3 and 1/2. The problem is theres no way to determine "all active balances". I suggested limiting effectiveBalance a few weeks ago, but 300K seems excessively excessively harsh, and will also make a 1000tps network pretty much unfeasable, since it would require literally thousands of TF nodes that publish their IP and have DDoS protection, HA redundancy, etc |
|
|
|
I read that earlier today. did you read that? it was arbitrary, no math behind it. |
|
|
|
FORUMS.NXTCRYPTO.ORG users: Adminius over there is btc24 here. Seems to have just completely vanished, hit by a bus, something, whatever. Last login on either site was end of January. Not responding to any of my PMs on either site. Im not sure as to how long his equipment is paid up for - what happens if 1 day its just shut off? So do we wait for that day or do we try to do something now? This extended absence coupled with the fact that we still have no email password recovery coupled with the fact that we still experience unknown reasons for logouts gives me reason to post here and ask the community what are the thoughts? I will post this on the forums as a vote. https://forums.nxtcrypto.org/viewtopic.php?f=49&t=865If we want to migrate elsewhere, does anyone have any forums hosting they know we can use? I can change the DNS A record for forums.nxtcrypto.org to be whatever IP address whenever it needs to change. Community vote. Or maybe btc24 comes back. |
|
|
|
limit forging power 1/3 active balance. this means you need to continuously monitor which is the total active balance everytime and limit forging power to 1/3 active balance maximun per account. ok so you want to limit effectiveBalance to max value possible equal to 1/3 of balance. I dont understand your last sentence at all. What is the point of 1/3, why not 1/4? limit forging power 1/3 active balance.
this means you need to continuously monitor which is the total active balance everytime and limit forging power to 1/3 active balance maximun per account.
this can be interesting as inlet will penalize large accounts for small. You mean 1/3 of total active balance (i.e., of all accounts together)? Yes, this may be a good idea (not with 1/3, which is kind of critical, but, say, 0.1). I only don't know if this is computationally costly... I can read, but there is still something Im not getting from what you've recopied and pasted. How do you propose to limit "1/3 of total active balance (i.e., of all accounts together)" thats impossible to sum up, at least decentralized. Its just not possible for the network as a whole to know how much total NXt is forging. even if it did, who do you cut out to get to 1/3. Where do the numbers 1/3 and .1 come from. I still dont understand the problem we are trying to solve here |
|
|
|
|
wait. so ciyam got so butthurt that he not only leaves this thread but he locks the AT thread and wants people to come to his own forums board to discuss? wtf I dont understand how people let themselves get so butthurt over this
|
|
|
|
limit forging power 1/3 active balance. this means you need to continuously monitor which is the total active balance everytime and limit forging power to 1/3 active balance maximun per account. ok so you want to limit effectiveBalance to max value possible equal to 1/3 of balance. I dont understand your last sentence at all. What is the point of 1/3, why not 1/4? |
|
|
|
|
does anyone know if its possible to make the unix shell command curl accept only a certain self-signed certificate? I know there is the -k option to make it ignore security warnings but I want the server to use self-signed cert and for the curl client to allow it, but to not allow any other invalid certs.
|
|
|
|
I seriously want to see what all those people that have been bitching about Nxt not having a user-friendly client will say after using this KICKASS client!!!  By the way... hate to be doing this... but how about repeating the message below even when people want to choose the passphrase themselves... Attention: Don't ever disclose your secret phrase. If you lose it you lose access to your account! not just this, but a warning that funds WILL be stolen if a strong password isnt used |
|
|
|
|
CfB: how does payout during leased forging work? will the account owner (that all effectiveBalance values are leased out to) have to do manual reconciliation or does NXT just figure it out?
|
|
|
|
Someone's previous suggestion of "users being too stupid" or whatever it was... yeah right, sure thats really the way to go.
Might have been me, but I did say it needs to be made stupid proof. But make no mistake it is stupidity for anyone to lose their NXT because of a bad password even on the NRS client as it is. I can understand someone being a little lax when making an email password or something but when you're investing thousands of dollars into a new technology I would think any reasonably smart person would take a degree of extra caution. I studied bitcoin for a full week straight before I bought my first hundred dollars worth. I think part of it is on-line banking, which lets you get away with weak passwords. People think "if it's ok for my bank should be ok here" I'm not saying these people are "non-functioning" stupid, but they are stupid nonetheless. I think it's kind of similar to the people who don't like bothering with reading the manual when they are putting together something complicated from IKEA. They are confident they'll figure it out and just start putting it together. Usually they swear a lot while doing it and mess up a couple of times. With crypto the consequences are more dire. You cannot screw up even once. It's hard for me to garner a lot of sympathy for these people. me either, but logically it just makes more sense in that if we have an option where we get fewer fingers pointing our way, then that method will be the way that NXT will spread larger/faster. A nxtwallet.dat file by default gives us that. |
|
|
|
Is DoS expected to be more of a problem with TF than regular forging? If we can guess who will forge the next block with a high degree of probability, won't an attacker do the same?
If this was already discussed, can someone point me to it? I'd like to find more detailed information on how TF is planned to be implemented.
I brought this up, in the original TF thread I think it was, the answer was that the forging pools that publish IP address so as to participate in TF will also require some DDoS protection, be it actual hardware in the case of owned/operated forging equipment or as a cloud service in the case of using a VPS. This is why in the long run, using odroid/RPi forging devices as a network in a TF enabled system will be a no go. |
|
|
|
optical, bidji29. i think you are (we all are) biased because we know this shit for a long time. what the fuck is a wallet file. but a password, hell, everybody knows that.
But newbie don't even need to know there is a wallet.dat when they first launch the client. They directly have an account and can send NXT on it. It's an easier solution. I'm only talking about the first second after someone launch the client, because that's the most important ones. It's the key. Each additional step neccesary to use NXT = Less people who will bother Come on. Do you really think a wallet file, which can get corrupted, or lost ("oh i deleted the program folder, didn't know that...."), or not found ("where is the fucking folder") is easier than a "please write this down"? we can make the same argument about writing something down "which can get corrupted, or lost" so not only do we want to introduce NXT to the world that's protocol is completely different than the de facto standard of bitcoin, we also want to change the main account access method? You guys are failing human computer interaction. Heres the deal: If we go the brainwallet method and people screw up, they look back and say "why arent you like BTC? if you were like BTC I wouldnt have lost my NXT. NXT sucks" Someone's previous suggestion of "users being too stupid" or whatever it was... yeah right, sure thats really the way to go. On the other hand if we go .dat file storage and they screw up, there is a long history of de facto standard that has precedence that protects NXT from blame. Do you have this protection with method of using brainwallet as default? nope you dont. |
|
|
|
optical, bidji29. i think you are (we all are) biased because we know this shit for a long time. what the fuck is a wallet file. but a password, hell, everybody knows that.
This is obviously not the case. Your argument is EXACTLY why people are losing money - even just now you called it a password. ITS NOT A PASSWORD ITS A PASSPHRASE there is a huge difference in the NXT application with a live public blockchain. People are treating this passphrase entry box exactly like you just called it (password) like they treat any password box they see, and people are still losing their NXT due to shitty passphrases, even with our best efforts at prevention with the warning we put up in NRS. Have you read it? On the other hand, .dat functionality is already in use by probably millions of people by now with BTC and other bitcoins. And there are tons of existing data backup options for users. Im not saying to get rid of brainwallet; its an extremely cool feature and required for online wallets. But its apparent that many people cannot handle it. It is bad practice to just say "well too bad for those dumbasses, they just cant handle it" We might could have got away with it had brainwallet come out before .dat file storage did, but we didnt. |
|
|
|
I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded) Thoughts? Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later. Do not get sidetracked into that discussion and then wait  It may not be *perfect* but it's WAY better than what we have. I agree, keep main track as is while we discuss the nxtwallet.dat default method. |
|
|
|
I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
But its really less confusing for newbie than Brainwallet / current wesley implementation No. you cant just come in here and say no and leave it at that. read my argument and refute it. that is if you want reasonable discourse, otherwise you get ignored. seriously tell us why "no". |
|
|
|
you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.
Eventually the new clients will go widestream and security will improve.
Guys, KISS (not literally). And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be. I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
you 2 do realize, that right now with no nxtwallet.dat file, AND a "big hint" the we currently have in all NRS clients that there are still people (yes morons, but what can we do) that are losing their NXT?" how is a .dat file confusing? the brainwallet function needs to be non-default; I consider it an advanced feature. No one can sanely argue this fact, given the big hints we give out but with idiots still ignoring the warnings. |
|
|
|
I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
what will happen if the user has already sent a fund to this less-than-15-chars-passphrase account but the fund has not been conformed and shown up in the balance yet? Should not allow to create a less than 35 chars pass phrase in the first place. I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
The first transaction of an account is always an incoming transaction and the secret for the recipient account is not needed for this first transaction. Thus, everytime NRS or a client would need a secret for an account and be able to reject it, it already does have at least one transaction. you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions. Eventually the new clients will go widestream and security will improve. |
|
|
|
One of the few interesting IT classes I took in uni was human/computer interaction, so here are my thoughts: I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded) Start page:  At the very least move the "not registered" link on top of the text box, not under it and make sure the program starts with the textbox NOT having focus. But my REAL suggestion is for the textbox to go away completely upon running of the program: to by default implement a wallet.dat type of wallet be implemented, with autogenerated if possible by browser (not keyboard/mouse movement input) 256bits of entropy stored on local file nxtwallet.dat as the key. Then on each boot, look for this file and if its not there, create a passphrase and store it. Dont even show the passphrase to the user. Then make access to manual brainwallet passphrase entry require a bit of work to get to, with warnings along the way. And then reject any brainwallet passphrase under 15 characters unless that account already has a published public key. If brainwallet is used, then just create a null nxtbrainwallet.dat file and upon boot, if your program detects a null nxtbrainwallet.dat file, then skip the part where you look for nxtwallet.dat, and autoprompt for a passphrase. also, provide ability for user to convert back from brainwallet to using any previously-saved nxtwallet.dat file in case they do have some NXT in there. also, provide ability for user to encrypt nxtwallet.dat file, just like the BTC wallet does. But make it apparent that this encryption key is NOT in any way associated with brainwallet. I wish some big whale would offer a nice bounty for someone to open source a client with all my listed requirements - this is really what NXT does need. In a big way. You would only get bounty after successful source audit. Would also need some way to audit updates. Whales??? ETA: by just hiding the passphrase from user in wallet.dat you can use 25 words in the dictionary. Or whatever is required to obtain max usable entropy |
|
|
|
|
Im glad to see TF fully coming to fruition soon. Though to realize its 100% full potential will require all the forgers to begin to lease forging power to accounts that TF forge on public nodes that publish IP address. Otherwise then when its time for an account to forge a block that is not participating with a published IP address for TF, then it cannot receive direct transactions from clients - clients will have to rely on the current broadcast mechanism for their transactions.
And I really wish we could limit effectiveBalance. Not to punish the whales, since they can just lease out their power to different pools. But to actually force a measure of distribution out there.
FTR, Im planning on running a forging account on of the nxtcrypto.org VPSs. I will beef up its CPU/mem, and will see about getting some DDoS protection built in. Will have to shut down API/User interfaces and just leave P2P port open. I will create a vanity account with a very short acct# (currently looking for an 8 digit account, may have to use a 9 digit one) and it will forge with only 1 NXT and everyone can lease out their effectiveBalances to it. Hopefully the other VPS admins out there will do the same thing. Ill work on a HA system for a pair of VPSs that can work together and each can forge with the account if the other is having issues. So hopefully will have a very high uptime % figure.
|
|
|
|
I'm not sure of the exact balances - but yes I do think they were "set aside" and will stay there no matter what happens "with the price".
When you look into the design of TF it certainly favours larger accounts and I don't think that was "by accident".
But the bias is very small, right? I mean, extremely minute, right, by like .0001 or something like that, right? At least this is how I understand it from the other thread where this was discussed. |
|
|
|
|
Show Posts
) are welcome! 
