Topic: Transparent mining 2, or What part of Legacy should be left behind (Read 15635 times)

Thanks.

Some consequences:

None of this requires thinking of Nxt as a currency (or in fact, Nxt at all. I've tried to avoid terms like "blockchain" which I suspect have a lot of pre-established "freight", I prefer to talk about the more general concepts like "version of history"). Nxt, or rather effective stake, is just how often you get to update a version of history, i.e. how much say you have in the history. Right now, I think of Nxt as a way to come to consensus on a version of history. Not just a history of $ transaction, but potentially for any events that can be recorded digitally.

If Nxt is not a currency, then it doesn't make sense to talk about profiting from requesting events to be added to versions of histories (transactions). It does make sense to make such requests free. But in practice, in Nxt, current technology is still limited, we need to limit (ab)use with a cost to transactions. If we are to have costs, it makes sense for such costs to depend on the type of tx being sent (as in fixed fees), since different txs have different costs in terms of space and processing requirements of the entire network. Rather than depend on the amount of Nxt you're sending (as in proportional fees), since the more effective stake and influence you have, the more you should be able to do.

(I think jl has already talked a lot about these last two paragraphs, just in different terms.)

Will read shortly, thanks for posting.

Dealing with many versions of history:

In the approach described in the above posts, you can never be sure which version of history is the right one, in fact, it's not meaningful to talk about a "right" version of history, only different versions of history that you have different confidence about. It may turn out that one version of history preferred by H right now may not extend to the version preferred by H in the next block. For the most part, that's ok, because most versions will be identical except for small differences due to transactions not reaching the deciders/dropped. So you just request to add your events to your most preferred versions of history as determined by H, and stick to just the most preferred resulting versions of history.

To avoid dealing with an exponentially growing tree of histories and save computing resources, you can discard the least preferred versions of history. e.g. if H is the lowest sum of HIT/EFFECTIVE_STAKEs, you can know the probability distribution of the lowest HIT/EFFECTIVE_STAKE during each block by sampling previous blocks. If you know that the difference between the lowest HIT/EFFECTIVE_STAKE and say the 10th lowest HIT/EFFECTIVE_STAKE has never been greater than e and will likely almost never be greater than e, then you can just keep the history with the lowest sum SUM of HIT/EFFECTIVE_STAKEs in memory, along with just those histories whose sum are less than SUM + e and discard the rest. In the unlikely event that the versions of history that the rest of the network prefers are built on an old version that you discarded, then you end up on a fork, and you'll have to deal with it manually by redownloading the histories from somewhere you trust.

This is when all the actors are honest. When there are dishonest actors, then large differences from deliberate actions by them can occur. So the problem is how to discover who they are, and consequently blacklist them and reject their versions of history. This could be done outside the network of actors and events, through e.g. RL investigation. It could also be done within the network. e.g. if the versions of history broadcast by a certain actor frequently don't include the events involving you that are sent to them while other versions of history do, that suggests that actor is not being honest with you. You may want to prefer other versions of history that did include your events (or if you think it's not a big deal just try to include that event again later based on the same history, when it is a different decider's turn), and you may want to increase their blacklist weight, and announce the discrepancy to other actors so they can likewise increase their blacklist weights.

The history preference function H:

(This part I don't understand well. Please help me improve my understanding.)

H is supposed to select a preferred history (or rather like D, a sequence of histories of decreasing preference) to build on from a set S of known possible histories, so write H(S) to represent this.

I think you want H to be consistent with D: Suppose you're at a version of history h right now, and D chooses as decider account a_1 as the first candidate, a_2 as the second candidate, and so on. If the updated versions of history proposed by each a_n is h_n respectively, H should prefer h_1 over h_2, h_2 over h_3 and so on. One way to achieve this is for H to prefer the version of history with the smallest sum of all previous HIT/EFFECTIVE_STAKEs of previous deciders in that version of history, since if you have two versions of history differing only in the last block, the HIT/EFFECTIVE_STAKEs are all the same except for the last decider, so the version with the smallest sum is also the one whose last decider has the smallest HIT/EFFECTIVE_STAKE.

But folks in the main thread were talking about largest sum of 1/EFFECTIVE_STAKEs (of just the deciders?), which isn't consistent in the way I described here, so I don't get this part. Am I missing something?

---

H should likewise be consistent with any blacklisting used, I'm not sure what a good modification would be.

The decider function D:

We want each actor to be selected as decider with frequency proportional to their effective stake. But each actor may not be reachable (online) all the time. They may also not be honest or accurate. So we want D to select not just one decider, but a sequence of candidate deciders of the next versions of history, so that actors can have a choice between alternative versions of history via the preference function. We also want D to be based on the version of history h you wish to extend with your current events, we write D(h) to reflect this.

One way for D(h) to satisfy this is via:

1) For each account with a positive effective stake, roll a deterministic die based on the history h you wish to extend. Call the result HIT
2) Order all such accounts in increasing HIT/EFFECTIVE_STAKE.
3) The first account that is reachable (online) is the first candidate, the next reachable account is the second, etc.

This D does indeed choose each actor with frequency proportional to their effective stake, as the number of accounts with an effective stake grows to infinity. (subject to simple niceness conditions; ask me if you're interested in the proof).

When you want to extend a version of history with your current events, you send a request to the first few candidates. Send to more to increase the chances of your events being included in some version of history.

---

I think the above is what's known so far about TF, from BCNext via CfB. This assumes all actors are honest and accurate, which not all will be. Below is one possible (untested) modification:

Each actor maintains a personal weighted blacklist of other actors that they believe to be dishonest, inaccurate, or otherwise do not wish to send their information to. The weights are probabilities of not choosing them as a candidate decider and so not sending your events to them when you would normally do so. So a weight of 1 would mean never send them any events. Weights are updated as new information is gained about other actors and your confidence in their honesty and accuracy changes.

Wanted to clarify my understanding of Nxt's TF approach to proof of stake. Going to try to write it out here, hope folks can comment/correct/ask about stuff and help me improve my understanding. I'm unable to keep up with the main thread, sorry if all this has been brought up before. Thanks!


Regard time where events (transactions) are occuring as discrete (say in 60 sec blocks). The consensus problem: how do we get a group of actors (Nxters, nodes) to come to an agreement on a common, consistent version of history (blockchain branch), given that no one can see the entire network at any point in time, each actor only knows about his own actions, and maybe the actions of actors near him. And this becomes more difficult as not everyone can be assumed to be always honest or accurate.

The simplest way to come to consensus is to accept what one actor decides as the version of history. This is the starting point of Nxt. So the general consensus problem now reduces to the problem of agreeing on which actor should be the one to decide (forge the block). Let D be the function that determines who is the one to decide.

Again, the decider does not see the entire network. In order to get information, other actors must send information about their events to the decider. It's inefficient to send information about all of your past events, so to simplify, each actor sends only events that they originate during the current block of time and state which version of history these events are based on. The decider then updates the version of history with the information received. The other actors may not see the decider as well, so after updating the decider broadcasts the updated version of history to other actors, who continue to help broadcast it.

We cannot have the same actor always decide, since they may not always be honest or accurate. So we need to regularly change the decider, have different actors decide for different blocks of time. We don't necessarily want all actors to decide the same fraction of the time, i.e. to not all have the same say. Call the proportion of the time where an actor gets to decide their effective stake. So effective stake is a measure, and basis of an actor's influence in the version of history. This is why we say Nxt is proof of stake.

Even if everyone agrees at a point in time to one actor's version of history, that version may not be honest or accurate. So we need to be able to switch versions of history, to prefer one history over another. Call this preference function H.

Let's investigate the properties that D and H should have, and then hopefully be able to define them.

(There is a third function I that determines which events the decider wishes to include into the updated version of history. This is not so important, I think it can be left up to each actor, so I won't go into it here.)

How does Nxt have nearly the same amount of value potential that it otherwise would if it's not a coin but more of a stock in a company that releases other coins?

Also, I'll say it again, deflation is not such a bad thing: http://www.forbes.com/sites/eamonnfingleton/2013/08/11/now-for-the-truth-the-story-of-japans-lost-decades-is-the-worlds-most-absurd-media-myth/

My vote is keep Nxt as a coin as well as building upon it and sure allow competing coins to be built on top of it and indeed allow Nxt to be a share in the company that controls other coins but no reason not to use it as a coin as well.

This would be a great idea, do you have the know how to develop?

yes, JLP has already come out and said the conversion to NXT-cents, and to allow for .1 as a fee will be more complex, exactly for the reasons you state.  you can see in the code that in some places its just a long/integer and some other places there is a 100L division.  He is going to have to standardize before we get the new functionality

Storing all numbers as integers, and then placing the decimal point afterwards allows for all kinds of error.  This kind of "floating point" math has cost lots of people lots of money over the years.  As of even a couple of weeks ago, some parts of the Nxt code expressed amounts in full coins (1 Nxt = "1") and other parts expressed in in terms of Nxt-cents (1 Nxt = "100").  Hopefully I don't have to explain how that can cause trouble.

In case I do: imagine a situation where a third party has created a payment processing system that has been deployed by hundreds of people running servers.  Each person has this software running, and is happily processing transactions.  One day, the Nxt core devs decide to move Nxt from two to four decimal places, so that 100 coins which used to be represented as 10000 are now represented as 1000000.  They implement the change, and roll it out.  Everyone running that payment software on their own servers have to SIMULTANEOUSLY be ready to CORRECTLY interpret the change in their input data, so that they don't receive "1000000", think it means "10000.00 Nxt", and suddenly cost someone and additional 9900 Nxt for their transaction.  The FEE would be 100 times too big, by accident, as well.

Deciding where the decimal goes from the outset, and then sticking with it (FIXED point operations) removes all of the risk of this kind of error.

I'm sure Jean-Luc knows what to do, so, if it takes time, there's no "Tomato/Tomato", there's refractoring.

Ah. Ok.  Makes sense.

I am thinking that using AE and AM is the best way to go, still working out details

Anything that has the same effect as a stock split is not really inflationary in the sense I am talking about. By inflation I mean whatever amount of NXT you have is suddenly (or gradually) worth not as much due to dilution. What you describe increases the nominal number of NXT, but whatever percentage of NXT you had is unchanged. So it is neither inflationary or deflationary

In what way, other than perceptual, is a fixed point representation of 100.00 different than the integer 10000?

Tomato/Tomato

Nope. Bundle of some units, say, 0.01-NXTs or NXTcents. 100s of it = NXTs.

Right now Jean-Luc working on that - to implement easy divisibility for cents and for any needed zeros after point in fututre instead of current model.

I'm not sure if the best way to have more coins on top of Nxt is to use the asset exchange, or build a new coin on top and use AM for storing the new coin's blocks.  Both methods will need to be explored, I think.

Common knowledge is that there are ~1 billion NXT.  Take a look at the source and you'll see a bunch of multiplications by 100L -- adjusting for displaying/thinking in cents.   There are actually ~100 billion NXT.  Every time you send 1 NXT, you're actually sending a bundle of 100 NXT.


Sure it can.  Everyone just has to agree that the multiplier is now larger than 100L.  If everyone agrees the multiplier is now 1000L, there will be an order of magnitude more NXT than right now.

It's a pain in the butt at the moment since it requires everyone to update their software with a hard-coded change.  There's no reason in the future the multiplier can't be a variable, however, and the size is agreed to by software voting.

Isn't this smart contract stuff?

I still think NXT is made for the people and should address their very personal needs like supporting the family, financial security, legal certainty and the like. This is even more important in case somebody dies.

In NXT nobody should trust anybody. But people need trust. So, what I have in mind would be decentralized notary (DN). A third party bound by cryptography and algos.

An account holder could tell the DN to sign something and to do something for him in a pre-defined future:
 - to pay amount x_i to some accounts
 - to send encrypted messages to certain accounts in order to reveal knowledge
 - to execute a script
Everything the DN does is invisible to everybody except those how own the keys.

Use-cases could be:
 - when a father wants to hand down his fortune to equal parts to his two sons
 - signing documents like contracts, birth certificates etc.
 - when a real-world corporation changes leadership

BCNext said: Trust nobody.

That's certainly the best advice somebody could give. However, another smart guy told me this:

In the end, you have to trust somebody.

What exactly do you mean by existing methods? Notaries?

Sure 1 billion Nxt can be used as currency, look at the Satoshi.. we can just subdivide Nxt into say 0.0001 Nxt = 1 credit and then 1 Nxt would be equivalent to $0.12, if it grew to be the same size as the US dollar.  Why not, I feel like Nxt itself has to have some inherit value to it and using it as currency where people would keep their money as Nxt would be a good way to do it.

Because here's my thing, if we're not using Nxt, then why would someone making such a new coin stock up on a bunch of Nxt?  Once we allow it to be further subdivided, why not buy 10,000 Nxt, and subdivide it into 100 million small parts and call each one of those tiny parts 1 coin of this other currency.. I mean somehow you'd need to factor in that Nxt would be required to pay some very tiny fee to the forgers to prevent spamming but I don't see any limit.

If we do distributed computing, I think that would need to be built it right into Nxt, not on top of it but I could see distributed computing, and distributed storage, and other apps being profitable and paying the forgers to forge, seeing as those have already been propsed.. I guess I won't give up hope on that ending up integrated into this coin yet.

Thanks for the replies James!

Wish BCNext would come on here himself and find some way that we could discuss these ideas directly with him.. I guess him throwing out the ideas and letting the community decide which direction to actually go isn't a bad idea either though.