I'm talking about client side in memory (in the user's browser in my case).
As I said, prepareBytes also validates server side. It checks to see if the asset you are placing an order for exists, if you have enough money to pay for that asset etc.. If you try to sell, it checks to see if you have enough if the asset exists, if you have enough of the asset to sell of, etc.. As you can see, prepareBytes takes just 1 API request, whereas another client would have to do multiple (check if asset exists, check if enough of asset to sell, etc). If the client does not do error validation this it will always think it returns successfully (broadcastTransaction does not verify).
So I am dumbfounded as why you would want to disable this, since it may actually result in _less_ api calls. Also I think there should be no made up words like "ultralight" and "light" clients.
oh well in that case the original question doesnt apply if the client doesnt sync the blockchain and actually forge. And I do see your point now on less server load - that does make sense. I do still like the ultralight term for a client though, especially since now it seems like not so bad of a thing anyways. |
|
|
|
Is this "getLastBlock().height > 303" a flaw? for (i = 0; i < block.numberOfTransactions; i++) {
Transaction transaction = blockTransactions.get(block.transactions[i]);
if (
transaction.timestamp > curTime + 15 ||
transaction.deadline < 1 ||
(transaction.timestamp + transaction.deadline * 60 < blockTimestamp &&
getLastBlock().height > 303)
||
transaction.fee <= 0 ||
!transaction.validateAttachment() || Nxt.transactions.get(block.transactions[i]) != null ||
(transaction.referencedTransaction != 0 &&
Nxt.transactions.get(transaction.referencedTransaction) == null &&
blockTransactions.get(transaction.referencedTransaction) == null) ||
(unconfirmedTransactions.get(block.transactions[i]) == null && !transaction.verify())
)
{
break;
}
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp. hmmm 302 blocks is less than 1 day |
|
|
|
@Wesleyh
Where can I see how much there is left to forge a block?
Time? I don't think there is such an API. And I think it's better to hide it anyway, since most of the times it's depressing to see how long it would take  Thoughts? I agree, it provides more confusion than value. there is the getForging API that requires secretPhrase That requires keeping secretPhrase in memory and sending it to the server in plain text, not good.. btw did you see my previous post about preparetransaction (directed at you)? secretPhrase is always in memory anyways when an account is forging. and yes that API should a POST to an HTTPS url. I did get it, not much else to say though except I still say if an ultralight client has to decode the VPSs response anyways in order to verify it before the client signs it and sends it off, then it may as well just do it all to begin with. And yeah I handt considered the mass of other APIs that VPSs will have to serve, which makes it even more desirable IMO to be able to limit some things. For example, if a server starts to get overloaded, it may want to stop serving ultralight clients but still take in signed transactions from light clients |
|
|
|
I am assuming that it is possible to configure firewalls to only accept incoming connections on specific ports to a list of specific IP addresses.
Could somebody confirm (or deny) this assumption?
I want to create a set of guardian servers that are the only ones that accept connections from random clients. The servers that actually do the "money" work, would only accept incoming connections from these guardian servers. This would isolate the pool (and multigateway) servers from the internet and I think provide good protection.
This way, we can make doing a Ddos attack require attacking all of the guardian servers. Since these guardian servers really only need to run a very small validation and relay layer, there is no reason the work of the guardian servers couldnt be spread across a large number of servers. Not quite fully decentralized, but a lot less vulnerable than having a single pool server.
James
yes, any hardware based firewall or freebsd/linux pf/iptables can do this |
|
|
|
@Wesleyh
Where can I see how much there is left to forge a block?
Time? I don't think there is such an API. And I think it's better to hide it anyway, since most of the times it's depressing to see how long it would take Thoughts? I agree, it provides more confusion than value. there is the getForging API that requires secretPhrase |
|
|
|
lulz and CfB was the 2nd reply in that thread |
|
|
|
|
Do you devs yet have any ideas on the APIs that will be involved in leasing effectiveBalance? In order to assist with remediation, hopefully there will be something more than just leasing and recalling your effectiveBalance. From the leasee's perspective, upon generating a block and receiving fees, it will be necessary to determine each individual effectiveBalance it is leasing as of 1440 blocks before the pool's generated block, and to then make sure that each effectiveBalance never went down during the next 1440 blocks.
So Ill propose an API to allow an account to request a list of all accounts leased out to it as of a certain block. Or if you are feeling generous, with this info, also provide the effectiveBalance of each account at that certain block. Or possibly even something similar to guaranteedBalance that lists a guaranteedEffectiveBalance of 1440 blocks as of a certain block of all effectiveBalance's that you are leasing. Now that would be IDEAL
|
|
|
|
If we agree that it is no ordinary coin for the above reasons, then we should consider Ricky's point about NodeCoin altering the very fabric of Nxt; and not just brushing it aside as just a coin anybody can create on top of Nxt.
Personally... I do view Nodecoin as just a project/asset/coin... but let me make one thing clear... IF the intention of " Nodecoin should be redeemable for accessing services (DAC, NxtCash, whatever)" was to exclude NXT from being used as well... then it is definitely a NO GO. I Agree... Last time I checked, the only reason to any Nxt service (DAC, NxtCash) was to spend/receive Nxt, so why would using any of those services exclude Nxt? We have a Nxt platform and apart from the core, anyone should be allowed to develop anything they want on top of it. If we don't encourage complete openness to our platform, others will develop in alt POS coins. The fact that this forum is having philosophical issues with NodeCoin should tell you that there is something fundamentally wrong with the way Nxt implements Assets. It is not only Nxt that has this problem, Mastercoin also has the same problem. its not a problem. some people are just ignorant of the facts of how NXT works, and how an asset works. |
|
|
|
All right people please explain this to me;
Is it possible that some criminal have an automatic bot that all day long is guessing the secret passphrase for NXT accounts. If the bot found a passphrase that GOT some NXT in it, send it to one allocated account and if there is NOT NXT proceed to next guessing. If you do this with very power computer / bot for a long time this will have success. How long will it take that the NXT accounts are all discovered?
Can we build something to prevent this?
they are already doing something much better than you describe. prevention is having a strong passphrase |
|
|
|
why have you not been backing me up in the past when I have been suggesting this?  I don't read all the posts. For everyone's reference to discuss: I view the fee as a blockchain spam deterrent, any possible ROI is secondary IMHO. We don't have any major activity on the blockchain at the moment. All is relatively quiet, but that will change as services are added and merchants begin to use NXT for payment. After only a few short months of very little activity the full blockchain is already over 50 megs on disk.
I think the fee should only be changed if the price of NXT goes up significantly. My 0.25 NXT minimum fee vote was based on the thought of 1 NXT going to the stable range of $0.15 to ~$0.30 cents US in the next six months.
I still say trying to tie the fee to some FIAT is the wrong direction. Ill say it again - a transactions's fee should be tied to its byte size on the blockchain. So lets say a NXT transfer is 128bytes, and its fee is .1NXT, so then an AM or alias transaction of size 256bytes should then cost .2NXT, and other transaction types follow the same method of fee determination. We would determine a "base" transaction that is the smallest possible transaction, and set the .1 NXT fee to it. (or .01 or .05 or whatever the community decides) and then scale every other transaction's fee to be based on its size compared to the base one. But no one likes my idea.  This proposal will require a bit more code; but for the moment I think a straight .1 NXT for all works, as it will encourage more use for now. |
|
|
|
Nxt have a better innovation compared to other altcoins popping up everywhere, but the only thing that is keeping it from progressing is the inability to mine Nxt when you have zero balance from you account or even if you have a thousand of it, decentralize means it is not controlled by a few big stake holders.
I proposed an option for "mining" Nxt. Technically, this isn't mining, but if someone were to do this, we could all use our SHA-256/Scrypt hashing power to acquire Nxt. I first posted this over at the Nextcoin.org forum ( see here). Please join the discussion and if anyone who reads this knows of an experienced pool admin who might be interested, please refer them to this topic. The really cool thing about this approach is that people will most-likely not mine Nxt to dump it. They will mine Nxt and the process will pump it, rather than suppress value! Practically any way you look at this approach is a benefit! This is a really cool idea. I might be interested in setting up the pool and a script to interact with coinwarz and an exchanges API and hosting the pool if there is some bounty. Whales? Ive been working on a script that will control 2 VPSs that work in conjunction for high availability to control a forging account on only 1 of the VPSs, where if a VPS croaks, it automatically picks up on the other VPS. Since its bad to forge with the same account on 2 systems, Im developing this mechanism to support a HA forging account for everyone to lease their effectiveBalance to my pool. Im nearly done with this little project (except for the remediation part) and could spend some time next on the PoW pool with auto transfer to an exchange and purchase of NXT based on APIs to an exchange and data it gets from coinwarz. |
|
|
|
It's a bit of a disgrace they only pay 1 fee for sending al those hunderd-thousands of NXT. Sometimes I think the fees should be relative to the amount of NXT. Something like this:
< 10 000 NXT send = min. 1 NXT fee
10000-100000 NXT send = min. 10 NXT fee
100000-1000000 NXT send = min. 100 NXT fee
> 1000000 NXT send = min. 1000 NXT fee
In the future this could be, because we want to lower the fees:
< 10 000 NXT send = min. 0.01 NXT fee
10000-100000 NXT send = min. 0.1 NXT fee
100000-1000000 NXT send = min. 1 NXT fee
> 1000000 NXT send = min. 10 NXT fee
What are your thoughts? The big guys earn of the fees of the small guys now, so it's more fair if they pay more for transactions?
Fee should depend on data size coz it solves a technical problem (spam prevention). An attempt to make it depending on sent amount is an attempt to make the world more "fair". Don't mix technical and political/ethical problems, plz.why have you not been backing me up in the past when I have been suggesting this? |
|
|
|
I have completed migration of my 26 VPSs to SSL. As they are on 0.8.9, HTTP is not available, only HTTPS, and I have also enforced POST for APIs with sensitive data to ensure the sensitive data is encrypted (using HTTP GET instead of HTTP POST will expose secretPhrase, even if SSL is used). I am the only one with access to vps1 - vps12 on nxtcrypto.org and other people have access to vps13 - vps26. Even so, I would still highly recommend against using secretPhrase even on vps1 - vps12. That being said, the CA that signed my VPSs' certs is my private self-signed cert. So it is not signed by any public CA, and as such will error out if you enforce host verification (you should do this) unless you include my CA (so, yes you should do this as well) in your HTTPS client: -----BEGIN CERTIFICATE-----
MIIDkTCCAnmgAwIBAgIJAI0O0DJBZfATMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxGDAWBgNVBAMMDyoubnh0Y3J5cHRvLm9yZzAeFw0xNDAz
MTEyMDM4MjZaFw0xOTAzMTAyMDM4MjZaMF8xCzAJBgNVBAYTAkFVMRMwEQYDVQQI
DApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQx
GDAWBgNVBAMMDyoubnh0Y3J5cHRvLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKjp9XhKSFzLv100077WiZl6F0XqP36KOdw1rRjFMteeQVfPoEp5
2D/Y10klFT80s9tcp7dYjSRuRJ9yNy9DbCD4zKYcBquFIICzcxdcf3UdjupWY2mf
RMbra8zuWvJFo/nEHsbCDrEB4WC/+6qssNzJd7Xsr3v4SKESFQXQrjZtNwMkz46N
ilhAWRjrzC7CCrkxVk3BQ5k9UFD8UBM7g14qDfQQvCgiNgxm7t8tCxF2uXckHLUa
QB45DqP3zfRNtf6t99ChVcWgBDw6IZsHFq6C88zBTvY5rvp7BALNl3vjYNkiv1h1
rLIRKtjHOukrF6bIkTPDY/p9bJnzH1shXGMCAwEAAaNQME4wHQYDVR0OBBYEFDk1
zmSgctw/7ejjL0QB9EQ/0HboMB8GA1UdIwQYMBaAFDk1zmSgctw/7ejjL0QB9EQ/
0HboMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAFwxj+SVOQez4qrh
2jMDpTKRzMHWK60oSLol/GfJa0naAxY0IR/Afg0aNnzRkpzVW13GIpkXzs/J8j1K
ccIOzbpnLsjOpC9IWgDTT0/3uzi9+mLT/25cXhiOPZuS5qyJ5GsNQQVsalnaLill
doAupKnozftWbYbu5x8/bCSj2HmEBVsXANP9GjcoNtHIPqHCjDAAERyCBw+ZFCR8
nhfuehBHCUp7rccdgYHjkCDEGckt2Cw6VcHhzM+vAigOZwtnOEDg38qENUaWuQPs
IqnPEmLRL9ohFyQ/7bJzXxFyIVxiaUwtHnlNmqB7cF5f2Ud5kpjCYJu4f/83Bs3y
Q0Ib3Cw=
-----END CERTIFICATE-----
|
|
|
|
It doesn't make sense to write what you call an ultralight client then.
Why would you not implement this yourself in a client and have a trustless solution?
THESE 2. JLP, can you add an option to allow NRS to only process certain API requests from localhost? Why? The prepareTransaction is good to get server side error handling (one shouldn't rely on client side error handling), when we get the response back, we can "unpack" it and see if it's the same as our input, if so, broadcast it out. You shouldn't disable this functionality. Im thinking about it from a network design and scalability perspective. IMO the scalable way do handle things is with a light client. A VPS will be able to support 2x more light clients than unltrlight clients. |
|
|
|
It doesn't make sense to write what you call an ultralight client then.
Why would you not implement this yourself in a client and have a trustless solution?
THESE 2. JLP, can you add an option to allow NRS to only process certain API requests from localhost? |
|
|
|
Good job Jean-Luc for implementing client side transaction signing and confirming the need for SSL between client and server for security!
I've missed that. Could you point me to where he said that? its due to the use of an "ultralight" client versus a "light" client. The API that JLP has just completed allows for an "ultralight" client to submit transactions to a node, where the node prepares the transaction and gives bytes for the ultralight client to sign. So if clients implement this "ultralight" functionality, then not only is SSL a must, but then these ultralight clients must implicitly trust that the VPS operators wont screw them over and steal their NXT. As a VPS operator, this worries me. What if the VPSs I run get hacked? Then I'll get blamed. Contrast a "light" client that figures everything out on its own, but since doesnt maintain a blockchain, it submits the completed signed transaction to a VPS where SSL then is not that huge of a deal. |
|
|
|
I should have local (trustless) signing online tomorrow ( no password sent to the server). A big thank you to CFB, Antonios, BloodyRookie and Jaguar0625 for all their help with this  I want to make sure people understand that it is not "trustless" signing. Unfortunately, the way we are doing it, you still have to trust the server. You don't send the password to the server, but you sign an array of bytes that the server sent to you. How do you know that this array really represents the transaction you intended to sign? To be sure, the client would need to parse and verify it, so the client needs to know exactly how each transaction type should be represented as a byte array. This is not a secret, it is in the source code, but if you need to implement this logic on the client side, you might as well construct the byte array yourself, and not trust the server to do it for you correctly. So by letting the client be simple and lazy and let the server construct the byte array, you necessarily have to trust the server. Furthermore, you have to trust that the server response you received has not been modified in transit - and the issue of using SSL to talk to the server becomes important again. Wait... is it possible for a client to sent a transaction request to a VPS and the VPS to determine client balance and use that as the amount and change the destination account to his own account, and , then wrap all that up in bytes for the client to sign and submit to the network? if so this is a BAD idea, regardless of if you have legit SSL certs or not. ETA: I mean its a BAD idea to develop this "ultralight" client, if what I say is true. Then a "light" client which does all the work itself and just broadcasts the signed transaction to the network is the only way to go |
|
|
|
What about a TF coin?
It will be awarded to all the nodes that publish their IP address that enables transparent forging. Based on the nodecoin discussion, I am convinced this will kill TF. After all, anything that reinforces a certain behavior is sure to do the exact opposite.
James
Edit: Too late, I just issued TFcoin. TF is doomed!
can you issue an emulecoin while youre at it? |
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Release 0.8.9
...
WIll there be a similar update for the 0.7.x train? Or it is obsoleted? The reason I ask is that all of a sudden, with 0.8.x train I get isolated on my own fork very frequently, causing restart of java with old blockchain. I went to 0.7.7 and problem went away. |
|
|
|
|
Show Posts
