Switch to ArdorForum

The remaining pieces of transparent forging, such as prediction of next forger and blacklisting of those missing their turns, will be implemented, if really necessary, after the issue of full blockchain pruning is solved, which is after 2.0.

For now, the improvement in making the block times more regular and avoiding long blocks, which is already implemented by improving the base target adjustment algorithm and will take effect at the 1.7 hardfork, is sufficient, and with the number of transactions we have there is space to grow before an increase of possible transaction throughput will be really needed.

Thanks for the reply. I am more interested in understanding TF so that I can talk about it (rather than "when will we have X TPS?!" thoughts I think you read into my post  )



This is where I get confused. Come-from-Beyond said:

Quote from: bitcoinpaul on October 19, 2014, 04:05:54 pm

... TF is a mix of different mechanisms and not fully active yet.

... TF is just an ability to "predict" the future. All the other is bells and whistles.

And I thought that this was the "Prediciting the future" that you can see in real time here

The release notes for 0.4.8 (couldn't find original but I remember it) back up that TF is released.


I have also seen CfB describe TF as multi-layered, having 'x'% complete (as bitcoinpaul thought in the quote above and you describe in your last post). So that led me to wonder if there had been a change to TF (as BCNext had described it) that didn't require the bells and whistles.

At the moment, I think:
Transparent Forging bootstrap = Ability to predict the next forger with high degree of probability (released at block 30,000 in NRS 0.4.8 )
Transparent Forging = Predict the next forger(s) + Economic Clustering +...  (and we will also be able to have exactly 1min blocks if forgers don't miss their turn, replace the base target and other advantages)


So please correct me. And perhaps define some terms we can all use and refer to, if required? I don't think many can confidently list the main moving parts of TF, let alone describe them I imagine they have the same uncertainty I have when I try to read up on it.

Thank you

@JL, from the code, could these be interpreted as being steps towards 'full' Transparent Forging implementation at the blocks listed?

Looking at the constants we can see that 8 steps have been made so far:

Code: [Select]

public static final int TRANSPARENT_FORGING_BLOCK_2 = 47000;
public static final int TRANSPARENT_FORGING_BLOCK_3 = 51000;
public static final int TRANSPARENT_FORGING_BLOCK_4 = 64000;
public static final int TRANSPARENT_FORGING_BLOCK_5 = 67000;
public static final int TRANSPARENT_FORGING_BLOCK_6 = isTestnet ? 75000 : 130000;
public static final int TRANSPARENT_FORGING_BLOCK_7 = Integer.MAX_VALUE;
public static final int TRANSPARENT_FORGING_BLOCK_8 = isTestnet ? 78000 : 215000;

Thanks again. I will try to find out more from those other guys.

Quote from: Jean-Luc on November 09, 2015, 05:17:30 pm

The remaining pieces of transparent forging, such as prediction of next forger and blacklisting of those missing their turns, will be implemented, if really necessary, after the issue of full blockchain pruning is solved, which is after 2.0.

For now, the improvement in making the block times more regular and avoiding long blocks, which is already implemented by improving the base target adjustment algorithm and will take effect at the 1.7 hardfork, is sufficient, and with the number of transactions we have there is space to grow before an increase of possible transaction throughput will be really needed.

I second what JLP said here.

Now, I would say that there is no such thing as the transparent forging. Of course, the idea is that the next forgers (at least, several of them) are known in advance, and this would make several things (such as instant transactions) possible; but this is partially true even for the current algorithm. The details of the transparent forging are still awaiting discussion; anyhow, as stated above, that's not urgent. One possible proposal is in my "Math of Nxt forging" paper. Also, very old CfB's posts on this are probably outdated; I remember we discussed one TF proposal with him, and that proposal turned out to be unsafe.

Thanks for the reply mthcl.

I guess being able to predict the next forger means you know where to send your transaction to allow it to be 'instantly' confirmed, that is what you mean by partially implemented?  [speculation] This reminds me of a feature CfB called 'Time Warp', so perhaps this is a bit of Nxt magic that allows a tx to be considered confirmed before the next block? This sounds impossible but so does most things I read  . This is based on 1 confirmation == 1 block [/speculation]

No, the solution of my paper was not mentioned by CfB, but I recall he had a favorable impression about it. In any case,
 (1) I know for sure that CfB is very occupied now, so don't expect too much from him;
 (2) as JLP said, all this is not urgent. Of course, it would be nice to have the solution of my paper tested; but I cannot do it myself (I wrote last program around 20 years ago). Anyone wants to create a Nxt clone with this TF algorithm?..

I was skeptical, although silent about feasibility of transparent forging from the very beginning.
It's now about a year or more, since they say that TF needs Economic Clustering. Now my questions are:

1) How different is Economic Clustering from Ripple consensus system (at least as it was devised in 2011)

Let’s say a node has a public key that the client generates for them. There is no connection between this key and a wallet key. It just allows you to be sure you are talking to the node you think you are.

So when you run a node you choose which other nodes you trust. So you could say “I trust my 3 friends’ nodes, Gavin’s node, and these 5 businesses’ nodes.” This trust just means that you believe these people will never participate in a double spend attack or otherwise manipulate the ledger.
The ledger would basically be like the current bitcoin block chain but it would also have a list of what nodes believe the current ledger to be valid. <hash of current ledger signed by node’s public key> (This list doesn’t have to be complete. Nodes can just collect this list as needed. They could even just ask the nodes they trust if they think the current ledger is valid since those are the only ones they care about)

Transactions are still sent to all nodes connected to the network. There would be a network wide timestamp. Transactions would only be accepted if they were within a certain time period of the network timestamp. So you would need to wait maybe 10min before you could fully trust a given transaction. After this waiting period you could be sure those coins weren’t double spent.

If a node ever encounters two conflicting ledgers it would just go with the one that was validated by more nodes that it trusts.

So there should always be a consensus among the trusted members of the network.

There would be a way to look up particular nodes in the network and ask them questions. (I’m imagining this whole thing running on Kademlia, a DHT)

2) Since they are probably quite different, after all Ripple wasn't a PoS crypto, aren't those differences unnecessary superstructures complicating things over Economic Clustering trust layer?

3) Is TF still in plans for Ardor/Ignis?