Show Posts - colin012
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - colin012

Pages: [1] 2 3 ... 43
NXT Metals is Closing!
Buyback Starting on January 1st, 2018 at 1:30 AM UTC!

NXT Metals is closing down due to lack of interest. To keep good faith with the community, I will be buying back assets and MS Currencies for all kinds of NXT Metals Tokens.

All tokens that were listed for sale before the timestamp of this post AND are still listed when the buyback starts, will be purchased for the price they are listed on the exchange!

This is regardless of the current buyback price for the tokens (as defined in the next section)!

If you have already listed tokens for sale, you can take best take advantage of this by calculating the buyback price in NXT (formulas listed below) and checking it against your currently listed price. If your price is higher, do not relist for a different price. You will get the price you listed for! If your price is lower, relist for the calculated price before the buyback starts!

All NXT Metals tokens listed for sale after the timestamp of this post will have a dynamic buyback price based on the current price of NXT and the current current price of the respective metal. Information is available in the next section of this post.

No NXT Metals MS Coins (namely NMAUA)
that are mined after the start of the swap will be honored.

Only coins mined BEFORE the swap starts can be swaped! This means you have until January 1st, 2018 at 1:30 AM UTC to mine NMAUA. Please cease all mining of NMAUA after that time.

Buy Back Price Calculation Information:

Note: All NXT to use price data comes from here: https://coinmarketcap.com/currencies/nxt/

Gold: NXTMetalAU (Asset) & NMAUA (MS Coin)

Issuing Account:
Asset ID:
MS Currency Code:
MS Currency ID:
Metal Price Data:
{Max Swap Price} = ({Gold Price per Gram in USD}
/ {NXT USD Price}) + ({Gold Price per Gram in USD}
/ {NXT USD Price} * 0.10)


1) NXT already has aged stake so you are about 1.75 years behind BCnext. hehehehe. 

But seriously, it does, it is just all or nothing over 24 hours.  The is a very important security feature.  As the NXT blockchain is immutable after 1440 blocks, but the coin age is also 24 hours.  So this effectively prevents somebody from faking they have a bunch of coins and attacking, because those coins will have to have been aged in.

2) NEM takes this a bit farther and the NEM chain is immutable after 360 blocks but coins are aged in over around 30 days.  The formula is basically 10% of the remainder that is not yet vested.  And while this just makes it that much harder to pull off NAS, I think the NXT method has been proven secure.  After a year and a half of people claiming NXT can be attacked, yet nobody ever doing it, I think just making the coin age requirement longer than the blockchain's reconfiguration age and one is safe. 

3) NXT (and NEM) are still susceptible to a good ole fashion 51% attack if somebody was able to collect keys for 51% of the coins, and while PoSAS would slow this down, it wouldn't stop it.  If somebody accumulated 51% of coins in PoSAS, I'm guessing they could still take over the chain, they would just wait a little longer than a day as the coins were aged in.

1. I am very aware of this. I would call NXT PoAS rather than PoS.

2. Same as 1 bit for NEM.

3. A 51% attack on PoSAS would require 51% of all accounts with a stake, requiring large stake holders to split their stake up amount multiple accounts and pay the TX fees for each transaction IN Addition to having the funds to supply those accounts with. By controlling that fee, it can be made more expensive than 51% of coins (even past 100% of coins) to control 51% of accounts though they don't necessarily have to control all these coins at the same time.

PoMAS (my most recent update to PoSAS) takes this a step farther by introducing a minimum balance greater than the smallest possible unit of coins. By controlling this value, you control the necessary stake held at a single moment to gain 51% of eligible accounts. If the minimum balance is 10, and there are 100,000,000 accounts with a minimum balance of 10, then to control half of the accounts, you would need to control (0.5*10*(100,000,000+1))+10, or 500,000,015 coins at the same time. This is in addition to the one time fees necessary to fund an account with 0 balance. Because one would have to simultaneously control a very large number of coins (as it is with NXT's PoS) AND pay many one time fees to place those coins in new accounts (the sum of these fees may even exceed 100% of all coins in existence), it is even more secure than PoS as far as the cost of a 51% attack.

Making it secure against other types of attacks (such as Future Control attacks where a user manipulates the block they submit to control the account that gets the next one) is where it becomes difficult. I suppose it would also be possible to perform a Time Window Control attack where a user runs a DDoS on public nodes to shut them down for the time windows before their submission becomes eligible to improve their odds of getting a block. This could be avoided if the window, after time eligibility was initially met, lasted until 10 seconds after a valid block was received rather than 10 seconds after becoming eligible.

General / Re: The PoSAS (Proof of Some Aged Stake) Algorithm
« on: May 07, 2015, 05:46:28 pm »
No time to get through all of this tonight, but I read the intro.

How is this different from the concept of coin age like Peercoin and others use?

As far as I am aware, Peercoin is still a true Proof of Stake coin where the more coins you have, the more coins you get from "minting" as they call it. In the system I am presenting, it doesn't matter how many coins you have as long as you have more than 0.

So, rich guys simply distribute their stake to 1000s of smaller accounts and therefore have effectively a higher change of generating a block?

That is the only problem I see so far in PoSAS but I think it is preventable. The trick is making it so that doing something like that is more trouble than it is worth. I have toyed with a few ideas in my head but I think I have come up with few ways that, when combined, will successfully make this behavior more trouble than it is worth:

1.Variable minimum Tx fees for funding accounts with 0 balance. The trick to this is making a minimum TX fee expensive enough so that the extra forging profit received by the extra account will not exceed the fee spent to fund it for a very long time. 100 years should suffice. This presents a new problem: no one will want to fund new accounts at all due to the high fee and this makes a barrier for new users. To aid in this, a special smart contract can be made where the "sponsor" of the new account is automatically paid back.

2. Requiring a fee for ever account sending funds in a single TX. This makes it so that people with funds spread across multiple accounts must pay more to use them together and that in order to even use funds from an extra account, it must have more than the minimum TX fee.

3. Variable stake age requirements. This would mean that for people funding a large number of accounts, the accounts they fund must wait longer to be eligible. Accounts with sponsors that aren't eligible to forge must wait as long as their sponsor has remaining to wait or a period of time dictated by the normal wait time formula. The wait time will automatically be lowered if they are funded by a sponsor with lower wait time for accounts it funds. So, let's say someone is funded by a sponsor and must wait a year but a different sponsor with only a wait time of 3 days, then they would only have to wait 3 days.

General / Re: The PoSAS (Proof of Some Aged Stake) Algorithm
« on: April 29, 2015, 12:50:25 pm »
No time to get through all of this tonight, but I read the intro.

How is this different from the concept of coin age like Peercoin and others use?

As far as I am aware, Peercoin is still a true Proof of Stake coin where the more coins you have, the more coins you get from "minting" as they call it. In the system I am presenting, it doesn't matter how many coins you have as long as you have more than 0.

The Proof of Minimum Aged Stake Algorithm

     The Proof of Work (PoW), and Proof of Stake (PoS) algorithms both have fatal flaws. First of all, both algorithms are vulnerable to Greater than Fifty Percent (>50%) attacks. In PoW algorithm cryptocurrencies, if any one person or group of people controls greater than 50% of the computing power (which is a real risk with large mining pools) then the blockchain can be rewritten. In PoS algorithm cryptocurrencies, if any one person or group of people controls greater than 50% of the currency itself which may seem an impossible feat except for the fact that in PoS currencies, the rich are always accumulating a greater percentage of coins with every block they are awarded which inevitably leads some individual or small group of people owning more than 50% of the coins.

     Aside from this, there are other issues with each algorithm. In PoW algorithm cryptocurrencies, a large amount of electricity is used up mining, which is wasteful and expensive. Further, it relies on a central hashing algorithm, which is weakened or broken by advances in cryptography and/or computing, can lead to attacks on the blockchain. In PoS algorithm cryptocurrencies, the rich always get richer which causes social and economic problems therefore making PoS currencies ineffective for widespread use.

     This whitepaper aims to explain a new type of algorithm for use in a cryptocurrency, called the Proof of Some Aged Stake algorithm, with the lofty goal of eliminating the aforementioned problems with PoW and PoS algorithms. This is achieved by selecting the miner of the next block in a deterministic, yet unpredictable way. This is so that anyone in the network can confirm the legitimacy of that miner's right to that block but cannot tell who that miner will be before the previous block goes through.

The Meaning of "Minimum Aged Stake"
     This algorithm relies on the ageing of an account's stake to verify that the account was not expressly made to claim a block in the near future which is why it is said that the stake is "aged." However, it does not matter how much stake an account has when it comes to who gets to mine the next block so long as they hold a minimum amount, which is why it is said that the account has a "minimum stake." Together, the algorithm proves the account has, at least the "minimum stake," not necessarily a large stake, that has been "aged" for some period of time. Hence, it is said that there is "Proof of Minimum Aged Stake."

The Decision Among Eligible Accounts

Choosing a 256 Bit Number
     Among accounts that are deemed eligible to mine the next block (i.e. they have a minimum stake that is sufficiently aged), one is chosen based on the signatures (there are 2 block signatures discussed later) of the block that came before it. The length of those signatures must be at least 256 bits long and a multiple of 256 bits long because those signatures gets signed with 256 bit signatures and it is ideal that every 256 bit output is as evenly represented as possible for any single account signing them. If the signature is between multiples of 256 bits in length, some 256 bit combinations are guaranteed to represented more often than others for a single signing account. If the signatures lengths together only total 256 bits long, then even one collision between 256 bit inputs guarantees that one 256 bit output is not represented at all for a single signing account; if they total at least 512 bits long, it is much less probable that one output is not represented for all given inputs and a single signing account. Now, because the more multiples of 256 bits means more evenly represented output, the transaction signatures are added to the block signatures before they are all signed together.

Selecting Who's Block to Use
     The block is selected based on whose signature produces the largest 256 bit number. To prevent everyone from submitting their blocks all at once and slowing down the entire network, a new group of possible winning values, starting at the top, is selected every second and stays open of 10 seconds. It follows this equation to determine the end of the next eligible group:


     The beginning of the next eligible group can be determined by the end of the last eligible group minus one. After 10 seconds of being eligible a group is no longer eligible. If no eligible group submits a block after 70 seconds have passed, eligibility is expanded to all accounts with a balance greater than 0. If a valid block has been submitted and the eligibility window closes on it, it becomes the new block and the second block signing period opens.

The Second Block Signature
     Because it is feasible that one could add transactions to themselves to the block they are making and manipulate the signature to improve their odds of winning a second block, this block must, itself, be signed by another person who does not have control over the transactions included in the block. For this reason, after the first block is accepted, a second block signer is selected in the same way as the first. It uses the same set of eligible accounts as was used for choosing the block creator with the exclusion of the account that signed the first block. The 70 second countdown starts over so that accounts who missed their window to be the block creator have a second opportunity to sign the block.

Determining Which Accounts are Eligible

Minimum Requirements
     Because it is feasible that someone may be able to predict which possible block is selected the block before it, a minimum of 3 blocks of stake ageing are required to insure that people don't fund new accounts with numbers designed to get the new blocks as soon as they come out.

Limiting the Use of Multiple Accounts to Increase Mining Chances

Minimum Stake
     In an effort to help cull this behaviour and to make 51% attacks more expensive, variable minimum balances should be employed block to block. The minimum balance should be such that the value of itself multiplied by the number of accounts it would allow to be eligible is at a maximum while the number of accounts it would allow to be eligible is at least 50% of all accounts with balances. In this way, the cost of a 51% attack is maximized while still allowing at least half of users to participate.

Fees for Funding Accounts with Zero Balance
     To further discourage this behaviour and increase the cost of a 51% attack, variable fees should be applied to funding accounts that don't have any balance. This be such that, with current averages, the mining reward for mining less than 1,000 years is not worth while. This can be represented as follows:


Where fn is the fee for the new block, Rn-1 is the average mining reward per block over that past 1,000 blocks, Bn-1 is the average blocks per day over that past 1,000 blocks, and En-1 is the number of eligible accounts in the previous block.

More to Come...

UPDATE: Sorry it has taken so long. I have encountered some trouble with finding out how to build a PPA. Thankfully, I have a new friend who may help me with it. The PPA will run on either OpenJDK 8 or Zulu 8 in an effort to make it more opensource.

Security / Re: Oracle Java trust issues: Rant and Solution
« on: April 17, 2015, 01:23:18 pm »
NRS 1.5 requires Java 8.  The latest OpenJDK that is available is OpenJDK 7 (at least for Ubuntu).

NRS has problems running in a VirtualBox with an encapsulated network driver.  All of the incoming connections appear to come from the same IP address (the IP address assigned to the host system link).  This causes problems because NRS assumes a one-to-one mapping between IP address and NRS node.

Edit: Bridged Adapter mode works.  It is the default NAT mode that has problems.

OpenJDK 8 is avalible for any Linux flavor... The problem is that there is no easy download/install instructions avalible for it. You basically need to compile and install it yourself. Zulu supports Java 8 and is easy to install but is only avalible for 64-bit systems so for a 32-bit system, you need to compile OpenJDK yourself if you want to use an opensource JRE with Nxt 1.5 releases. Maybe I will make instructions on how to do this tonight.

I also have a friend who may help me make a PPA (I have been having trouble figuring it out myself) that will install OpenJDK on 32-bit Ubuntu and Zulu on 64-bit Ubuntu then install Nxt and configure it to use the appropriate version of Java. This way the whole thing is set up automatically.

Pruning of messages (on testnet currently)

Thanks! That is pretty cool stuff!

Security / Re: Oracle Java trust issues: Rant and Solution
« on: April 14, 2015, 08:19:28 pm »

I agree. Just out of vague memory: isn't there a linux java that is called 'iced Tea' or something?
And then there was another open source implementation whose name eludes my atm...

but what about the gui client? does javascript have the same issue?

Iced Tea is an opensouce implementation of the Java browser plugins and Java Web Start, not the Java core.

JavaScript, as I understand it, is as opensource as the browser's implementation of it. Safari, Chrome, and Firefox all use opensource JS engines. I think Internet Explorer is closed source. Other I'm not sure about the smaller browsers.

General / BoneCP: A Possible Solution to the Nxt Speed Issue
« on: April 14, 2015, 08:03:43 pm »
Nxt is notoriously slow right now. I think it has to do, in part, with the CP (Connection Pool) library it uses. I don't remember which one it is using right now, but I remember doing some research and finding out that it is significantly slower than BoneCP a while back. BoneCP is opensource just in case you are wondering. :)

Security / Oracle Java trust issues: Rant and Solution
« on: April 14, 2015, 07:58:24 pm »

So, I have a problem with Oracle Java (basically any download you get for the Oracle Website... the JDK or the JRE)... I don't trust it. Why? It isn't opensource. This may not seem like a big deal because Oracle made Java, they are a major player in the computer world, and all antivirus software seems to trust them not to do anything malicious... so why shouldn't I trust their software with my computer, my personal information, and my Nxt password? The answer is that I don't trust anyone I don't know on a personal level who keeps secrets from me.

I am a programmer; I understand the desire to keep your source code secret. It is a desire for control, control of who gets credit, who gets money, and where future developments go. The problem is that by keeping your source code secret, you get a lot more control than that; you get complete control of what the code does and, on top of that, you get the privacy required to make the code to malicious things to computers that run it, things such as collect users' private data without them knowing or install backdoors into their computer.

I don't think everyone is out to steal my data or put back doors in my computer, but the less people I grant the ability to do so to the better! There are plenty of people out there who want everyone's data, regardless of what people have done, and some of them have nearly unlimited resources to do so (*cough* NSA *cough*). It is because of people like this, I try to avoid trusting people with my information if I can.

Seriously, if you doubt that the NSA has planted and/or paid off workers at Oracle to intentionally introduce and/or not fix backdoors in the Oracle JRE and/or provide the NSA with the source code so that they can find/exploit weaknesses before anyone else then you are just naïve.

By making something opensource, you are making its code transparent so that A: anyone who knows the language can find/fix security flaws and B: anyone who knows the language can tell if you have introduced backdoors and verify that the code is safe. Rather than trust a secretive computer program won't harm me, I would trust that a transparent computer program that millions of people who are concerned with privacy (like me) can look at and verify the safety of.

Solution for Nxt Users:

So, as it turns out, there has been an opensource version of Java (the JRE and the JDK) available for quite some time. It is called OpenJDK (it includes and opensource JVM and an opensource version of everything else needed for the JRE on top of the JDK). The problem with it is that there was no OpenJDK for Windows machines and it had to wait longer for bug fixes.

That is until 2014 when Zulu was announced. Zulu is version of OpenJDK with support for OSX, Windows Desktop, Windows Server, and Linux (including Docker). It also comes with quarterly bug fixes which is a plus! In addition, it supports older versions of Java than either OpenJDK or Oracle JRE/JDK which is another plus! There is, however, a down side to Zulu... It is limited to 64-bit systems. There is no 32-bit support. :(

So here are my recommendations:

(Almost) All 64-bit Operating Systems
Uninstall whatever version(s) of Java you have and install Zulu if you don't already have it.

32-bit Debian Based and Red Hat Enterprise Based and Oracle Linux Operating Systems
Uninstall whatever version(s) of Java you have and install OpenJDK if you don't already have it.

32-bit AArch64, BSD, Haiku, Mac OS X, MIPS, and PowerPC/AIX Operating Systems
Uninstall whatever version(s) of Java you have and install the appropriate OpenJDK port if you don't already have it.

Other 32-bit Operating Systems (e.g. Windows)
Uninstall whatever version(s) of Java you have. Install Oracle VirtualBox (it is opensource). Make a new 32-bit, opensource, Debian based or Red Hat Enterprise based Linux Virtual Machine (VM) and install the matching OS on your virtual hard drive. Then install OpenJDK on your newly made VM. Run all Java applications (such as Nxt) through the VM. This is the only way to guarantee that all Java applications you run are run in an opensource version of the JRE. I know it is a pain in the butt; sorry! :(

Solution for Nxt Developers:

Make a version of the Nxt Client in a more opensource language such a Perl. It will be difficult, but it will make it so that 32-Bit Windows users can still run Nxt in a more opensource environment (not truly possible with Windows but, for some, Windows is a necessary evil) without having to install a VM...

Or, I suppose, you could just wait 32-bit computers out because they are already WAY outdated; I'm not even sure that they manufacture them for personal use any more...

So, I am doing a special on Nxt for SuperNet Radio Network this Saturday at 2:00 EST. I was wondering what I should discuss. I have some ideas:

Java trust and security issues/resolutions
Smart Contracts

Anything else I should do my homework on?

Nxt Community News and Announcements / Re: SuperNETRadio Launched
« on: February 24, 2015, 12:45:50 am »
BTER hack and the security issues around it will be discussed on http://supernetradio.com 11 AM EST today

Listening! But I am a bit surprised about how less knowledge they have about Nxt.  :-\

- Nxt has 1 billion units (not 20 billion)
- Nxt isn't a different blockchain besides Bitcoin, it's a whole different cryptocurrency with his own code
- Nxt was first with the Marketplace, 100% proof-of-stake, Asset Exchange and so on.  :)

My bad about the number of units. I should have known that one. Numbers just don't stick in my head really well. Lol.

And, to be fair, it is on a different blockchain than BTC... It has its own code but it is still a separate blockchain.

Nxt General Discussion / Re: Nxt Hyperboria DNS solution
« on: February 24, 2015, 12:42:07 am »
There's a little glimmer of hope :)

So is NXT-based DNS the one we are all going to use now? Because it looks like this one actually works today.

What happened to Namecoin and the Rainfly thing?

* Quote taken from http://socialnode.hype


I will be discussing the BTER "cold wallet hack" from a security perspective on SuperNet Radio tomorrow at 11am EST. Specifically, I will be discussing if and how it is possible to "hack" a cold wallet and what you can do to insure that your personal cold wallet is safe! How could such a "hack" happen and what does it mean for the security of your cold wallet? Find out tomorrow at 11am EST!

Nxt General Discussion / Re: BTER
« on: February 16, 2015, 09:11:41 pm »
Just so everyone knows, I will be discussing this BTER "cold wallet hack" live on SuperNet Radio tomorrow at 11:00am EST.

nxtpit.ch / How much can nxtpit.ch offer.
« on: February 16, 2015, 08:32:33 pm »
I am curious. I have a project that needs over 7 million USD to start up. Would nxtpit.ch be able to handle that kind of load?

Consensus Research / Re: Consensus Research 2015
« on: February 16, 2015, 05:37:36 pm »
There are ways of doing history attacks without any NXT that are still reasonably possible. No need to buy a key. It would be difficult to do but still possible. I don't want to go into detail because I don't want to give anyone ideas. But the solution is more nodes

Pages: [1] 2 3 ... 43