@patmast3r *image_removed_for_space* I am using firefox last version, surely an issue from my side, maybe a bunch of updates I need to make (Ubuntu), I'll look at it but still weird. Btw if someone wants to use the online paper wallet generator locally with no NIS or NCC running, code is now on GitHub. Only local server, like wamp, lampp needed. No need to worry about storing key now, just run your own, with a bit of knowledge you can even personalise it  Ahh...Now I see what you mean. I guess it's best if you open an issue on github so the devs can see if there is a way to reproduce and then fix it. Haven't heard of this one before. Btw. there is an open-source organisation for all NEM stuff https://github.com/neweconomymovement/. Would you be willing to move the paper-wallet there ? If so someone needs to give you permission though. |
|
|
|
@Quantum-mechanics: what do you mean with " I'm going to the next."?
I add the address then when I click on "+add cosignatory", the address disappear, the field goes blank, only the top cosignatory address still set That sounds extremely weird. What browser are you using and are you maybe using any plug-ins ? Could you take a screen-capture (video) of this phenomenon ? |
|
|
|
@haggis: business rules are not yet thorrowly discussed so there is nothing at the moment we can present to you.
Thanks. Is there any ETA on this? As an originaly stakeholder (still) I'd rather like to experiment on this with NEM than Ether or something else  Go ahead and play with the other platforms and then come back and tell us what NEM should do better It's always best to learn from other's mistakes  |
|
|
|
We are in a last ditch effort to merge the old forum to Discourse but we ran into problems. If anybody has any experience with this kind of thing. Please help us out. Saul was able to get the accounts merged but not the posts on the threads. It is not just him. Lots of people have had this problem and had to hack their way through it, just our hacking hasn't turned out so well. One of our main sticking points is Ruby. Here is a thread documenting the problems. https://meta.discourse.org/t/importer-for-simple-machines-2-forums/17656/53You're having all of those problems ? Could you mabe post some specific error message or something like that ? I really don't feel like reading the whole thing since it's prob mostly useless. |
|
|
|
...
But I'm not sure it is a good way to automate transactions.
First I was thinking about using two accounts, an account to send automated payments to faucet users, this account would only contain small amount of XEM for security reasons. Every hours or days a bot send N XEM from main account to faucet account to refill it. So main account is safe. If anything's wrong only a small amount of XEM is lost.
Configuration would be:
[APP] => [NCC] => [NIS]
Request to remote NCC connected to remote NIS (don't know if it could work).
A cron would do the automated payment sending '/wallet/account/transaction/send' request to remote NCC, but wallet password still exposed if someone manage to access the server (main reason I thought about 2 accounts but the problem still there).
You can use multi-sig and anautomatated service to secure the funds so that they are secure even if the wallet on the server is compromised. Setup a multi-sig account with 3 co-signatories (Raise the number for security if you like and have some machines that need something todo). 1 - faucet 2,3 - automated signing (additional coding work, sorry ) faucet initiated the tx on request by the user. the automated signing kicks in either every x minutes or is constantly checking for signing requests. Now with some additional checks you can make one of those automated signers (or both) into watchdogs. -only sign x tx per hour -only sign tx with amount x -limit withdrawal to x XEM per day -anything you can think of As soon as you suspect compromisation you can also simply remove the compromised wallet from the cosignatories. If you deploy the 3 signatories i.e. faucet and 2 watchdogs on 3 different servers and you got yourself one very freaking secure faucet . I'm sure you'll find some people on slack who are willing to help out with their vps too. I'd also suggest to use browserfingerprinting to make it harder to request a lot of drips from the faucet. Might I think you just suggested the first ever decentralized smart faucet??? Only the sending of the drips or rather the signing of the tx happens decentralized. The faucet itself i.e. the website would still be centralized |
|
|
|
...
But I'm not sure it is a good way to automate transactions.
First I was thinking about using two accounts, an account to send automated payments to faucet users, this account would only contain small amount of XEM for security reasons. Every hours or days a bot send N XEM from main account to faucet account to refill it. So main account is safe. If anything's wrong only a small amount of XEM is lost.
Configuration would be:
[APP] => [NCC] => [NIS]
Request to remote NCC connected to remote NIS (don't know if it could work).
A cron would do the automated payment sending '/wallet/account/transaction/send' request to remote NCC, but wallet password still exposed if someone manage to access the server (main reason I thought about 2 accounts but the problem still there).
You can use multi-sig and anautomatated service to secure the funds so that they are secure even if the wallet on the server is compromised. Setup a multi-sig account with 3 co-signatories (Raise the number for security if you like and have some machines that need something todo). 1 - faucet 2,3 - automated signing (additional coding work, sorry ) faucet initiated the tx on request by the user. the automated signing kicks in either every x minutes or is constantly checking for signing requests. Now with some additional checks you can make one of those automated signers (or both) into watchdogs. -only sign x tx per hour -only sign tx with amount x -limit withdrawal to x XEM per day -anything you can think of As soon as you suspect compromisation you can also simply remove the compromised wallet from the cosignatories. If you deploy the 3 signatories i.e. faucet and 2 watchdogs on 3 different servers and you got yourself one very freaking secure faucet . I'm sure you'll find some people on slack who are willing to help out with their vps too. I'd also suggest to use browserfingerprinting to make it harder to request a lot of drips from the faucet. |
|
|
|
... Sure, I used the model view provided here and no type in it. $maindata = <<<JSON
{
"wallet": "KrakenLabs",
"password": "********",
"account" : "NCIZTWNWFWY4LT7DEKPRSCIKXMVXZS6FL6CE7IS4",
"recipient": "NAJPXZAQ2HMK72JILFPLJBC6MQLA3LPRLP4Y4NZN",
"amount": 6000000, //1000000 = 1XEM right ?
"fee": 4000000,
"message": "Testing",
"encrypt": 1,
"hoursDue": 18
}
JSON;
echo $nem->ncc_post('/wallet/account/transaction/send',$maindata); I guess the viemodel must be incomplete. It seems you ned to provide a value for "type" as well. Can't tell you what without looking it up in the docs. |
|
|
|
Why not run a local NIS ? That way you're supporting the network That would be nice but my old laptop just can't do it, I'll buy a VPS and a Pi for that later but for now I'm dry  that website runs on an old laptop ? plenty of free webspace around The website is hosted on a web shared plan actually, so I can't run NIS or NCC on it, my working station is quite old, with small RAM (2GiB) but way enough for what i'm doing Bad experiences with free hosting, I still prefer to pay if I have to. I tried to use TransferSendRequest post request (NCC API) and got {"timeStamp":11379450,"error":"Bad Request","message":"expected value for property type, but none was found","status":400} Well, did you provide a value for type ? It's easier for us to help you if you also show the code that produces the error or at least the json you POSTed |
|
|
|
Why not run a local NIS ? That way you're supporting the network That would be nice but my old laptop just can't do it, I'll buy a VPS and a Pi for that later but for now I'm dry that website runs on an old laptop ? plenty of free webspace around |
|
|
|
Thanks to all donators, it's really motivating (SSL on the way) I am trying to initiate a transaction using remote NIS (go.nem.ninja) and php2nem with /transaction/prepare-announce but got {"timeStamp":11320423,"error":"Unauthorized","message":"remote *** attempted to call local \/transaction\/prepare-announce","status":401}Before anything, is it viable to send this request to a trusted remote NIS for automated payments (via secure cron) ? If so, why do I have such error ? I would like to make things simple and light with no NIS or NCC installed locally, but I do not like the idea of having a private key stored in a file or even encrypted in a database as I still need to expose the key to decrypt it.. It would be awesome if any user could run a faucet in seconds on any web host using remote NIS connection. It sounds like that call is only available locally. There are some calls like that in the API. Sometimes because sensitive information would be sent over the wire, othertimes because you don't want any random person being able to make those calls. You can add additional local ips (as in remote IPs that are allowed to make those "local" calls) in the config file though. It seems in this case you'd have to send the priv-key over the wire which is not a good idea. http://bob.nem.ninja/docs/#requestPrepareAnnounceIn fact there is a fat warning in the reference (under 6. Initiating Transactions) not to do that So I'd advise to not add the remote ip as local ip in this case. Yeah I saw this fat warning box but I wanted to give it a try ^^. Thanks for your reply. I'm going to try something else today but involving a local NCC this time. Btw, SSL now active on the online paper wallet generator. Why not run a local NIS ? That way you're supporting the network |
|
|
|
Thanks to all donators, it's really motivating (SSL on the way) I am trying to initiate a transaction using remote NIS (go.nem.ninja) and php2nem with /transaction/prepare-announce but got {"timeStamp":11320423,"error":"Unauthorized","message":"remote *** attempted to call local \/transaction\/prepare-announce","status":401}Before anything, is it viable to send this request to a trusted remote NIS for automated payments (via secure cron) ? If so, why do I have such error ? I would like to make things simple and light with no NIS or NCC installed locally, but I do not like the idea of having a private key stored in a file or even encrypted in a database as I still need to expose the key to decrypt it.. It would be awesome if any user could run a faucet in seconds on any web host using remote NIS connection. It sounds like that call is only available locally. There are some calls like that in the API. Sometimes because sensitive information would be sent over the wire, othertimes because you don't want any random person being able to make those calls. You can add additional local ips (as in remote IPs that are allowed to make those "local" calls) in the config file though. It seems in this case you'd have to send the priv-key over the wire which is not a good idea. http://bob.nem.ninja/docs/#requestPrepareAnnounceIn fact there is a fat warning in the reference (under 6. Initiating Transactions) not to do that So I'd advise to not add the remote ip as local ip in this case. |
|
|
|
To anyone that may want to "virtually mine" the mining power will be exactly as valuable as the fees they are producing. Now that value might change over time but it will always be directly linked to the value of the original currency and how much of that currency i can mine with it.
Hmm.. 'Kind-of'.. It's not so clear exactly how much that is. If the mining power you have generates 100 coins a year, how much is that worth ? 101 coins, 106, 200.. 50 ? Would a free market help to determine that..? Depends on the value of the original currency and it's trajectory since I purchased the mining tokens I guess. I also don't see why smaller miners would be more likely to mine. They don't mine with their original currency so why would they be mining with mining power that they had to buy for their original currency ?
No - I am saying that small stake holders don't mine. If you want to mine you need to buy mining tokens. Then you can penalise those with mining tokens who don't mine, without affecting the regular small hold user. So that almost 100% of possible miners would then mine. I think.. I kind of see where you're going with this now. I don't see how it solves any real problems but it is an interesting thought. Your idea is basically to vritualize (as you aptly named it) POW-mining rigs by pegging mining-power to tokens that can then be purchased and tracked on the same chain as the coin that is being mined. I don't think it would be much different from other POS. You could speculate on mining-power but I'm not sure just how great that is. I'm wondering if it would make 51% attacks easier if people start dumping their mining-power because the coin goes to shiz. It just seems that it would make POS even more vulnerable to an attacker gaining a significant amount of mining power. It would also seem to be even easier to join/create pools which isn't exactly desirable. Just send me your mining-power and I'll mine for you and we share the earnings. |
|
|
|
Your assumption that The mining power could be worth much more / or less than the fees are producing.
just doesn't make sense to me. To anyone that may want to "virtually mine" the mining power will be exactly as valuable as the fees they are producing. Now that value might change over time but it will always be directly linked to the value of the original currency and how much of that currency i can mine with it. I also don't see why smaller miners would be more likely to mine. They don't mine with their original currency so why would they be mining with mining power that they had to buy for their original currency ? |
|
|
|
|
I don't see how introducing a second "currency" would solve the problem you are describing.
Say there is a second currency. Why do you think it would be more valuable than the original currency ?
There is no incentive to "mine" other than the tx-fees. So the miningpower-currency would only be as valuable as the tx-fees one can mine with it which is exactly the same as the original currency.
I'm probably missing your point...?
|
|
|
|
The delay was caused by one of the cosigners being on a business trip. After he is back this week, the last of the transactions will go out.
The business trip has not been going on for a quarter of a year Thanks for pointing that out! |
|
|
|
Something went drastically wrong at communicating to the public about NEMs features. Nobody is talking anymore about it on the trollboxes. And if you mention XEM you get answers like "lol xem". This is really disappointing as there has been so much work by the devs and others and it seems like nobody finds it useful  Maybe it's just me but the fewer attention NEM get's from people that hang out in trollboxes the better. |
|
|
|
|
I think most projects ignore bitcointalk because there's a lot of scum present and they just don't wanna deal with that.
Most crypto media seems biased to me anyway though. Coindesk should be called Bitcoindesk - pure bagholder talk most of the time imho.
|
|
|
|
Ok, so I deleted my old NEM wallet as a result of reinstalling the software. Everything works fine now. How do I retreive my old wallet without having to create a new wallet and re-importing my private key?
If you made back up of your wallet go to C://users/your user name/Nem/ncc/and paste your back up file there Ok, so I did that.. Now I get the message "ERROR 123 NIS: ADDRESS BOOK COULD NOT BE READ"
It's easier to just use the builtin function which will also backup your addess book along with the wallet. |
|
|
|
I don't know of any coin that couldn't be used as a coin for greece. It's not like there are many requirements besides being able to use it as currency and the means to exchange for EUR (which would prob be set up by greece if they decided to go that route).
I don't know of any coin that could be used as a currency of a whole nation. The scalability just isn't there. That's actually a good point. If the coins offers asset to asset exchange, then why not? Eg 30 assets of eggs for 17 assets of tomatoes
I don't think in a scenario like this anyone would be using an asset exchange. You go to the market just like you do know and then pay with %insertrandomroin% instead of EUR. Do you honestly believe all of a sudden small markets would start to put their entire investory into an asset exchange ? Not only would it be incredibly cumbersome it would imho also be unneccesary. In days of crisis and in days where economy was absent, wasn't everything dealt with exchanging objects? Well then I'd say people will do that face to face. Just because someone has an asset egg doesn't mean he actually owns the egg. There is no way for him to prove that (afaik not yet implemented in AEs). So they'd meet up and exchange that egg for whatever in person. I think the strengths of AEs up to now lie somewhere else |
|
|
|
Make at least a password of 32 characters. i have got a couple of NXT accounts for different use cases and every account has a password longer than 100 characters. they are very likely unhackable Yes but someone could steal your coins without stealing your computer if your password is weak. I don't see how any of this pertains to decentralization though  Don't make a weak password? He was asking whether it was a server-side login, rather than a client side. So I'm guessing you can't remember all of them. Do you store them somewhere in an encrypted file ? You see at that point there's really no difference to a "wallet.dat" anymore |
|
|
|
|
Show Posts
