You guys do realize Nxt is made in java right? 

I have made the current source code repository public:

https://bitbucket.org/JeanLucPicard/nxt/

Master branch is still 0.7.6, develop is 0.8.3 plus latest unreleased changes.

Is it safe to unlock account and forge on public node? Even that this node is my personal?

I have an active VPS with Hallmark pointing to my account
Should I forge with this account using the IP of the public node?

I have read that this is not safe.

Can I forge with this account with my private node and VPS with Hallmark continuous working well?

It would be good if, every time a new release is made, Jean-Luc (or someone else designated to the task), would email the exchanges and tell them to update their client. I'm sure they do not read this thread very often and other coins do not require that many updates.

i have a forging competition here, maybe you could enter if your balance was lower than 10,007nxt when you forged that block.

https://forums.nxtcrypto.org/viewtopic.php?f=2&t=744

 

And it's displayed in my client two times (for a reasignement it should only have one entry).

Perhaps if the alias is found to exist and not have been changed (in terms of the "data" part) then it shouldn't be broadcast as a tx at all?

SMTP not SNMP

NXTsmtp is just for proof of concept that incorporates something everybody is familiar with. I want to verify the peer verifiability of hardcoded NXTplugin followed by external NXTplugin. I am not worried about NXTsmtp for anything other than proving that NXTplugins work and are peer verified. At first I couldnt understand how on earth a DAC could be implemented. When I started thinking about email plugin, it became not as hard.

If the source to SMTP server is reviewed that it does send the email (backed up with test results) and as part of the sending process it adds a hash value of email to the blockchain. I think that allows peer verification, please explain where I am wrong. I am certain I have made mistakes somewhere and I am still coming up to speed with this whole decentralized blockchain approach.

The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

James

P.S. I usually dont post when I am sleeping or flying

25000 NXT bounty for a method and Java implementation that verifies NXTplugin process has not changed. Need an OS independent way of finding the executable code of a previously registered NXTplugin. This means we can constrain the creation method (linker output), probably need to do this for unix, Mac and Windows separately.

I am looking for a practical solution that will allow realtime verification by the NXTcore to make sure that the NXTplugin has not been tampered with. NXTplugins will have to be opensourced and publish signatures for specific compilers. This signature is then verified prior to any usage of that plugin by the NXTcore.

BEFORE we would ever consider submitting this to jean-luc, we of course need to test it like crazy. If the code is changed at all, we assume it is tampered. This probably means we cant do any dynamic linking, and need either static or relative jumps. Not sure though. Just finding where the code is might not be so easy. Figuring out how to get a ptr to the Java process will probably be pretty difficult. Any reasonable one way hash function is fine for this bounty, just want to get the system issues out of the way so we can validate in realtime that a plugin has not been tampered with.

As long as the source is reviewed for Evil Bobness and the code that is executing generates the same signature, I think we are getting close to where we can trust it almost as much as a hardcoded plugin where the plugin is actually part of the NXT core. Once we have the ability to have NXT plugins that are external to the NXT core, that is when things can really take off. We still need a formal validation process before it is approved for inclusion in the approved list of plugins, but maybe we can sidestep that issue by just having web.xml entries?

PLEASE if anybody can find a security flaw in this method, post ASAP. Remember Evil Bob is very evil

James

100 TPS is still a lot of transactions...8.64 million in 24 hours.

Could somebody check my node and Android TV stick? http://217.17.88.5:7874/
Seems to me that it is working, but in any case, check from outside world

Thank you very much. I think it's a shame that this happened.

Hey... have you seen this?   

https://bitcointalk.org/index.php?topic=345619.msg4863825#msg4863825

I want to provide a bounty for integration of a fully functional torrent client built into one of the nxt clients. Most importantly I want some type of decentralized magnet link system that provides useability at the level that a high quality torrent site provides (eg. Pirate bay level). I'm not a programmer/developer so I don't know, is this in some way possible? Is it a huge undertaking?

Let me explain then.

1. Download torrent file; you need to convert it to the magnet link to publish (will take <1min).
2. Go to the app page: http://95.85.8.113:9000/nxtnet
3. Go to link "torrent to magnet link converter (external)".
4. Upload torrent file there, copy the magnet link to clipboard.
5. Return back to the app page.
6. Paste the magnet link to the URI field.
7. Add description.
8. Add it! That's all

Yes exactly.  You guess the private key "since it was created by a human", then you crack the account.   That is why there are so many Nxt accounts that get cracked.  You don't even need to do the cracking against the network,  you just do it against the public block chain.

If the developers don't think this is fundamentally broken,  then I really question their judgement.

Can''t be fixed.   It is fundamental broken.   Exposing the private key (even if it is hashed) is just fundamentally wrong.