If there was a guide for how to run a static-IP / VPS node, I might be willing to do it.
It's the same as running a local node. Just set ur IP in web.xml. I've been looking all over for this little piece of information... It is not available on the wiki, or the OP, etc. There is something on the wiki http://www.thenxtwiki.org/wiki/How-To:CreatePublicNodeI havent checked to see how you nav to it from the wiki frontpage though, so you may have given us a littly job to do. |
|
|
|
Fixed a critical bug. Everybody should upgrade immediately. So my paranoia wake up. What is the bug?! Do I need to decompile pair of sources and do diff and than do analyse just before upgrade? Do you try to hide something from evil hackers? I think they are first who do analysis on decompiled sources... Don't waste ur time, it will be fully disclosed anyway. Shouldnt this announcement be in big bold red letters all over the place? How do you expect everyone to upgrade due to a critical bug if you don't make it seem serious and disclose the matter nonchalantly. Well I made it a global sticky at NXTCrypto Forums and have asked all translators to notify as well |
|
|
|
Might I suggest that you do not hold your breath as you wait for the apology?
I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death and don’t even think about apologizing (don’t bother doing it now in case your consciousness suddenly wakes up, it’s too late). And I am tired of being one guy on the other side of everybody else. A cohesive community is much more important than stupid arguments. ... Huh? Somebody gave you a death threat? That's crazy. ... he is referring to my previous PUBLIC comment to him in this thread that if he cant figure out how play nice here with everyone (what everyone else was asking of him) that he should go play in traffic as far as I was concerned. Notice he never used the phrase "death threat", but that is exactly what he wanted you all to think and you fell for more of his drama. Not sure what forum rules are regarding posting PM (it's a dick move at the least, unless illegal content) but he failed to include the rest of my PM since if he did it would not support his drama. Since I was the sender of the PM then I can justify posting it here: But I am optimistic that instead of being a complete jackass to everyone who you think is going off in the wrong direction, that you can instead provide better guidance instead of reverting to a complete jackass. I do see 1 recent instance of that, perhaps you can keep it up? i guess he couldnt |
|
|
|
I would be ok with moving to 0.1, but only full nxt numbers should be able to be sent.
So you cannot send for example 0.5 nxt to someone. The minimum you can send is 1nxt. will this be the case?
If you have 105.45 nxt, you can send 105nxt, the 0.45 can only be spent on fees.
im curious, what is your rationale behind this structure? and I am perfectly fine with 0.1, but if CfB *really* believes the price will jump we may as well move to .01. That would be what I call 'conviction'. But .001 would be asking for trouble at this point, IMO given that it looks like the system as designed supports only 2 decimal places. A decompile shows getBalance methods using some integer casting operations being divided by 100L. So how much extra work would it be to implement .001 versus .01? |
|
|
|
""Transparent Forging" allow each user's client to automatically determine who will generate the next block, so that they can then send their transactions to that node. This will also allow additional fees to be realized for immediate/priority transactions.
An equally important feature of Transparent Forging is an outstanding security feature of the protocol to temporarily reduce to zero the forging power of nodes who should generate the next block but don't. This transparent forging feature will prevent against even a 90% majority owner of all NXT branching out and forcing a fork. So if a node that has 90% of all Nxt, and doesn't generate a block when scheduled, the system will reduce its mining power to zero temporarily to prevent a bad fork from being forced. "
this is what I read in Nxt wiki... but can anyone elaborate why this really enhances the network security? I mean it´s kind of random who are my nodes at the moment so if I get unlucky
and have more then a bunch of nodes with bad intentions (double-spending or w/e) they could deliberately miss out on generating a scheduled block
and getting away with it.
Or is this not a problem in reality? Sorry if this is a really stupid question, but I´m really unexperencied with this proof-of-stake / forging as underlying security for a coin.
the best I can tell you is in TF, if you do not generate an invalid block when you are expected to, then it is assumed that you are working on a fork implementation. so then the network temporarily removes your forging power. all I got |
|
|
|
Could there be a small "lucky" part where a part of the transaction fee goes into a pot and once in a while the pot is given to some random wallet?
I suggested something like this for NXT but it was ignored. It kind of like a bonus lottery... I would like to implement such that block forgers cannot include their own transactions for free; where if they want to send transactions in a block they forge, then they perform the following: 1) determine the lowest fee paid for a transaction in the previous block generated. Trasactions belonging the block forger that he wants to include in the block must have at lease this fee assigned, or higher if selected. 2) use a defined algorithm (TBD) to select an account out of the previous 10 blocks that paid fees for transactions. multiple transactions with 1 account doesnt give you multiple chances, so if you had just 1 transaction you have equal chance of being selected as someone with 1000 3) the block forger takes the number of transaction of his own that he wants to include in the block and then multiplies by the figure obtained in #1 (or a higher fee than that if he desires, but at least that amount), and includes a transaction sending that amount of NXT to the account selected in #2. all his own transactions in this block must set the fee to value obtained in #1 (or higher if desired), as those will be returned to him if he does indeed forge that block. So as long as the math works out between these steps, the network will validate the block he forges. 4) if your own account is selected to send the fees to then the algorithm chooses a different account. This is to reduce the chance that exchanges with their high volume get their own free fees This structure effictively removes fee forging and makes a cool/fun little bonus lottery that encourages people to use transactions since then they become eligible for the lottery. |
|
|
|
+1
Please make addresses with some sort of error correction built in.
When I read what you guys are planing and saying I truly believe there is extremely bright future for NEM. I'm translating and hoping to join the community as a stake holder soon. I don't have money but I hope translating will suffice to enter.
Question: How come price of NXT is so stable?
I see that Vertcoin went up significantly in the past few days and what it brings to the table is not comparable at all what nxt has now.
Vertcoin jumped because it was added to cryptsy. imagine what NXT will do when it gets added to cryptsy. |
|
|
|
Hi there... I sent 0.055 BTC but unfortunately I sent it from Cryptsy... I just now saw that there is a stipulation that you cannot send from an exchange. I didn't see that the first time I read through the thread. T_T The transaction has already gone through so I can't get it back... Is there any way you could make an exception for me? Also, I recommend making that clause larger and in red or something because there is a lot of text in the post and also it comes AFTER the part in the instructions saying to send the BTC. I was just going step by step so I didn't see it until I had already sent the BTC. Anyway, the txid is http://blockchain.info/tx/3e54ea0468ae332722e5b23b384a83faff3685fde1570bd4ab7aa7fc6a05ed9bPlease let me know if you can accept my stake for this or if I'm going to have to spend another 0.055 BTC. :c I may be wrong, but i believe sending BTC from an exchange is fine. I think OP wants NXT to be sent from a wallet, not an exchange. Its not like everyone nowadays has a fully synced blockchain |
|
|
|
ok im gonna bring it up again, I forgot who it was before but I cant believe it wasnt wanted more...
I think we should integrate some error correcting code into addresses. Yes, a client software function/method can do this, and that is well and god, but what happens if (when) memory in a server that processes TONS of transactions starts to go bad?
Is it reasonable to just ignore this issue? Come on I mean we are talking about overtaking BTC and hitting 1000's of transactions per second here, why not add another layer of protection?
Last I heard, NxtChg (and ricot?) had already finished libraries for it in multiple languages. This is to make it easier for client devs to use. EDIT: https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524&start=190Isnt what they are implemeting a client-side only deal that only deals with user-typos? Im talking about the scenario were a client is experiencing memory issues and puts the wrong destination address into a transission, and having a forging node being able to detect invalid addresses from transactions it receives fro that client and to reject them. |
|
|
|
|
and another thing for our sw dev team... we seriously should consider using more complex addresses that incorporate error detecting codes that forging nodes can verify, so the forging node can reject a transmission should a sending node develop memory errors, and so the network can reject a forging node's block should the forging node develop memory errors.
Imagine the scenario were a high volume server that processes TONS of transactions and that server starts going bad...
|
|
|
|
|
ok im gonna bring it up again, I forgot who it was before but I cant believe it wasnt wanted more...
I think we should integrate some error correcting code into addresses. Yes, a client software function/method can do this, and that is well and god, but what happens if (when) memory in a server that processes TONS of transactions starts to go bad?
Is it reasonable to just ignore this issue? Come on I mean we are talking about overtaking BTC and hitting 1000's of transactions per second here, why not add another layer of protection?
|
|
|
|
Looking for a blockchain programmer to pitch my idea to on becoming the first 1Mtps service provider / forging pool. I have a plan and psuedocode; just need a competent programmer. No way I can do it myself - Just looking for a stake if you can implement my plan.
PM me
1Mtps? Do u mean "one million transactions per second"? I thought that was the figure being thrown around - am i off by 1000x? |
|
|
|
|
Looking for a blockchain programmer to pitch my idea to on becoming the first 1Mtps service provider / forging pool. I have a plan and psuedocode; just need a competent programmer. No way I can do it myself - Just looking for a stake if you can implement my plan.
PM me
|
|
|
|
UGH, CAN YOu get a mod to lock this one down? |
|
|
|
LONG and painfull.
THATS WHAT SHE SAID |
|
|
|
OK. I see. now I remember people saying before that the very first time that an account received NXT, that it had to wait 1440 confirmations before that balance could forge, but I also thought I remember people saying that after that first 1440 confirmation period, that then any new NXT received would forge immediately.
But I dont think this is correct. I just checked my account and that last few transactions in on it were received fees from forging blocks. and my balance is more than effectiveBalance by an amount that has almost 1400 transactions.
Unless received NXT from forging is treated differently than NXT received from some other account via a targeted transfer...
This was changed on block 47000. can you give specifics? Ill then update the wiki. Also I forged a block a bit over 1400 confirmations ago, and received 1 NXT for doing so. I checked the effective balance before and after that 1400 mark, and the effectiveBalance has yet to go up. So now Im really confused and I expected that effective to go up by when the block got 1400 confirmations. |
|
|
|
Reality:
1440 confirmations = ~48hs = effective transaction
Why?!
Transparent Forging is not working on 100% yet. OK. I see. now I remember people saying before that the very first time that an account received NXT, that it had to wait 1440 confirmations before that balance could forge, but I also thought I remember people saying that after that first 1440 confirmation period, that then any new NXT received would forge immediately. But I dont think this is correct. I just checked my account and that last few transactions in on it were received fees from forging blocks. and my balance is more than effectiveBalance by an amount that has almost 1400 transactions. Unless received NXT from forging is treated differently than NXT received from some other account via a targeted transfer... |
|
|
|
If the bandwith usage is too much for you, set shareMyAddress to false in web.xml, and remove myAddress (set it to an empty value). This should stop other peers from trying to connect to your node. does it affect forging? no it wont. this was my suggestion earlier when someone brought it up. in other news, can someone update the wiki on the getBalance API? There are now 3 fields returned, and the wiki only lists 2, and now with the addition of the 3rd field, the wiki is a bit ambiguous. Here are the 3 fields now: balance: 0 effectiveBalance: 0 unconfirmedBalance: 0 And here is what wiki says: Response
{
"balance": EFFBALANCE,
"unconfirmedBalance": UNCONFBALANCE
}
Where:
EFFBALANCE is the confirmed/effective balance in the Nxt account, expressed in Nxt-cents. This is the balance that is used for forging.
UNCONFBALANCE is the unconfirmed balance in the Nxt account, expressed in Nxt-cents.
Note: "unconfirmedBalance" is the balance minus all unconfirmed sent transactions. It doesn't include double-spending and unconfirmed received transactions. A user sees the unconfirmed balance in the client.
I would update it but Im not 100% on what to write. And can someone tell me how long it takes for a NXT transfer into an account for that new NXT to be available for forging? Does this time limit differ if it is new NXT due to receiving NXT in fees from forging a block versus receiving NXT from some other account? |
|
|
|
|
is there ANY way possible to get that current timer "You can generate the next block in..." via a unix command?
can we put a debug option for the java console to spit out the new timer estimate after each new block is generated?
|
|
|
|
|
Show Posts
