Pages:
Author

Topic: Transparent mining, or What makes Nxt a 2nd generation currency - page 2. (Read 35847 times)

legendary
Activity: 2142
Merit: 1010
Newbie
But most people with NXT will not have that... so how does this play out in the wild? 99 DDoS attacks on random victims who have NXT on their cell phone (and were supposed to forge the next block) and then the 100th is a hub so protected and the block gets forged? Also, what happens to the transactions that are being sent to DDoS IP addresses during the DDoS (or is that a non-issue due to the block never being forged with that IP)?

Those 99 ppl will lease forging power to the hub. The hub will be paying part of the fees back to their accounts.
newbie
Activity: 45
Merit: 0
There was a comment in this thread from a while back that got buried due to the poster being kind of a dick about the answer he got, but it was the reason I read through the whole thread to begin with, so I hope to get some clarification here...

Regarding transparent mining, and the ability to know the source of the next forged block: If a bad agent wants to attack the system, knowing the IP of the forger(s) seems like a ripe place for continuous DDOS attacks against unprotected victims. The prior answer was "forgers can use the Tor network" but that seems like a huge stretch to adoption as 99% of people don't know what that means much less how to set that up. Is that the real answer to this issue (assuming it is an "issue" to begin with)?

Thanks in advance.

It's not an issue for specialized hubs that forge blocks using leased forging power.

But most people with NXT will not have that... so how does this play out in the wild? 99 DDoS attacks on random victims who have NXT on their cell phone (and were supposed to forge the next block) and then the 100th is a hub so protected and the block gets forged? Also, what happens to the transactions that are being sent to DDoS IP addresses during the DDoS (or is that a non-issue due to the block never being forged with that IP)?
legendary
Activity: 2142
Merit: 1010
Newbie
There was a comment in this thread from a while back that got buried due to the poster being kind of a dick about the answer he got, but it was the reason I read through the whole thread to begin with, so I hope to get some clarification here...

Regarding transparent mining, and the ability to know the source of the next forged block: If a bad agent wants to attack the system, knowing the IP of the forger(s) seems like a ripe place for continuous DDOS attacks against unprotected victims. The prior answer was "forgers can use the Tor network" but that seems like a huge stretch to adoption as 99% of people don't know what that means much less how to set that up. Is that the real answer to this issue (assuming it is an "issue" to begin with)?

Thanks in advance.

It's not an issue for specialized hubs that forge blocks using leased forging power.
newbie
Activity: 45
Merit: 0
There was a comment in this thread from a while back that got buried due to the poster being kind of a dick about the answer he got, but it was the reason I read through the whole thread to begin with, so I hope to get some clarification here...

Regarding transparent mining, and the ability to know the source of the next forged block: If a bad agent wants to attack the system, knowing the IP of the forger(s) seems like a ripe place for continuous DDOS attacks against unprotected victims. The prior answer was "forgers can use the Tor network" but that seems like a huge stretch to adoption as 99% of people don't know what that means much less how to set that up. Is that the real answer to this issue (assuming it is an "issue" to begin with)?

Thanks in advance.
legendary
Activity: 1372
Merit: 1000
Thanks, as higher transaction speeds are possible due to predetermined mining nodes, one would expect the blockchain to grow faster than Bitcoin. Are there any ideas on how to distribute a super large blockchain while keeping it decentralized?

Or incentives decentralized hosting?

Few days ago I downloaded Elder Scrolls Online beta client, its size was 25 GiB. I don't think 10 GiB per day is a really big problem.
Not now but I it's potentially an uncertain variable I'd like to see addressed in an altcoin.
legendary
Activity: 2142
Merit: 1010
Newbie
Thanks, as higher transaction speeds are possible due to predetermined mining nodes, one would expect the blockchain to grow faster than Bitcoin. Are there any ideas on how to distribute a super large blockchain while keeping it decentralized?

Or incentives decentralized hosting?

Few days ago I downloaded Elder Scrolls Online beta client, its size was 25 GiB. I don't think 10 GiB per day is a really big problem.
legendary
Activity: 1372
Merit: 1000
How does the NXT blockchain work, does it grow in the same way as Bitcoin or is there an alternate storage distribution?

The same as Bitcoin.
Thanks, as higher transaction speeds are possible due to predetermined mining nodes, one would expect the blockchain to grow faster than Bitcoin. Are there any ideas on how to distribute a super large blockchain while keeping it decentralized?

Or incentives decentralized hosting?
legendary
Activity: 2142
Merit: 1010
Newbie
How does the NXT blockchain work, does it grow in the same way as Bitcoin or is there an alternate storage distribution?

The same as Bitcoin.
legendary
Activity: 1372
Merit: 1000
I was sent here from one of the NXT forums, and after reading the past 12 pages I have a greater understanding but I still lack some basics.

Thanks in advance for your explanation.

How does the NXT blockchain work, does it grow in the same way as Bitcoin or is there an alternate storage distribution?
legendary
Activity: 2142
Merit: 1010
Newbie
That's a fine example of how we fail to communicate.  I thought I was demonstrating the scope and extent of the problem in a more realistic setup and you thought I was showing that it was okay. 

Whatever, it's your call.  Decisions about NXT don't affect me at all anymore.

I think I'm going to drop out of this topic; it annoys me.

Actually u proved my point of view.  Smiley
legendary
Activity: 924
Merit: 1132


Cryddit already showed that forging is ok - https://bitcointalksearch.org/topic/m.4861016

That's a fine example of how we fail to communicate.  I thought I was demonstrating the scope and extent of the problem in a more realistic setup and you thought I was showing that it was okay. 

Whatever, it's your call.  Decisions about NXT don't affect me at all anymore.

I think I'm going to drop out of this topic; it annoys me.



sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
My analysis so far:

Below u'll find a short description of Nxt mining system. The description is based on text written by BCNext, I paraphrase it in my own words to protect BCNext's real identity against text style analysis (as was agreed).

I want u to pay attention to a paper titled Decentralised Currencies Are Probably Impossible But Let’s At Least Make Them Efficient.

The author writes:
Quote
To match this to the notion of “decentralised” (i.e. lacking central authority), the consensus group must be, at least, all participants in the currency. This does not present any real problem when that group is known. For example, it would be possible to define the group as “all people currently in the United States”– where the currency would be something akin to the US Dollar. Assuming the majority decide to behave honestly (as seems likely, after all, that is what happens now), then they should have no difficulty in forming consensus on who has how much money at what time. However, the most general notion of decentralisation does not admit such re-strictions. After all, in some sense, placing any such restriction simply pushes the central authority back a layer: instead of controlling the currency, the authority controls membership of the consensus group. A system like this must allow any entity to participate, and to join and leave the scheme at will. And here lies the problem. If you can never know who is in the scheme (bear in mind that knowing who is in is also a consensus problem!), then you can never get agreement.

In Nxt this problem doesn't arise coz all participants (miners) r known.

I agree.


This is a side-effect of 100% proof-of-stake currency. [...]


It is like 'PPC in its completed form'. Its contributors are going to eventually dismiss PoW. Right now it's a hybrid system with declining PoW part. In the end, it will become 100% PoS as well. PoS is like recycling the already-mined resources and by doing so, receiving a bounty for recycling and therefore maintaining the resource flow.


As u may know, Bitcoin et al. can be attacked by an entity that possesses 51% of hashing power. 2 main scenarios r possible:
1. Part of the miners leave the "legit" branch of the blockchain and start mining their own branch.
2. Someone buys/produces mining equipment and starts mining secret branch.

It even leads to centralization as the ghash.io case showed. NXT could have a lower centralization because of it energy-efficient nature.
HOWEVER, have a look at http://www.nxtio.org/. Unfortunately, at first, people will resist; they don't want to give away their money. But in the end, they will contribute therefore increasing the accounts of nxtio.org further and further.

I as much as I value TF, I think one issue of it is driving many small shareholders into such pools aka centralization.

The 2nd scenario can't be applied to Nxt, coz no NXTs exist outside the network. [...]

To speak in the words of the author of the paper above, buying/producing mining equipment is therefore equivalent to buying NXTs: it is acquiring consensus power.
In case of NXT, the maximum consensus power is known in advance. That power can be distributed but in total it will never change.


[...]
BCNext is satisfied with the results shown during last 2 weeks and now is going to adjust the mining algo a little bit to make it transparent.

What does this transparency mean? It means that anyone can predict (with very high probability) who and when will generate next block(s). And this gives us superior advantages:
1. Transactions can be sent directly to the miner who will mine the next block (if he decides to reveal his location on the Internet), thus saving traffic and coming much closer to VISA/MasterCard processing volumes.
I cannot see a flaw in that.

I would request some background data here: which nodes had a node sent its transactions to before TF was introduced? To each it is connected to or was there a special selection of nodes?

2. Blocks can be generated in advance and sent to most of the miners before they become valid (timestamp validation), thus greatly reducing rate of orphaned blocks.
So, when does this process happen?

When there are more transactions to be included in the current block than the block's maximum number of transactions would allow, right?

3. Due to ability to predict timestamps of future blocks (rate of blocks) it becomes possible to set appropriate fees to assure quick confirmations for important transactions (without paying too much for inclusion into a block).
That relates to my question about 2. How is consensus reached on which transactions are included when there are more than the block's max would allow?

Couldn't it be possible that nodes simply agree on not verifying a specific transaction and therefore excluding accounts from transferring NXT.

It has a certain similarity to OS scheduling (processor = block and has limited capacity to handle ops). Some processes are indeed more important and deserve more processing time but starving processes should be avoided as well no matter how small its priority is.

My conclusion here in case of TF, higher fee = higher priority and greedy behavior of forgers:
Bad Trudy knows the forgers in advance. So, it sends her big priority transactions to these nodes and therefore preventing the verification of other transactions.

One solution is therefore to increase the block's maximum number of transactions so far that makes it practically impossible to incent a forger to only forge Trudy's transactions.


And the most important feature:
The network can detect which miners don't take part in block generation and act accordingly.

The last point deserves to be described with more details.

Imagine someone is going to do a "51%" attack against Nxt and he owns 90% of all coins. The adversary must stop generating blocks for legit branch coz he won't be able to compete against 100% mining power with his 90%.

I don not understand that. If he has 90%, why does he need to compete against 100% and not 10%?

So he decides to "skip" his turn to generate a block. The rest 10% of the network detects this and penalizes the adversary by setting his mining power to 0 and distributing it among other miners. Now the network is back to 100% power coz everyone got 10-fold increase. The adversary can mine other branch in a secret place but it won't be able to replace the legit branch. Of course, the 2nd branch will have 100% "hashing" power tied to it as well, coz the attacker will get his 90% bumped to 100% but this can be counteracted by some mechanisms of advanced consensus (still not revealed).

Why just skipping? Couldn't a 90%-forger do much more evil things? Why not rejecting some transactions? Or verifying only its own?

Maybe, you can elaborate more one this.

As a 100% PoS currency Nxt is protected against a government wealthy entity that could buy/produce a lot of ASICs, with the transparent mining it's protected even against someone buying most of the coins.

Protected against not-creating a block.

So, what does make Nxt a really next-gen currency? Not those nice features like decentralized exchange, or decentralized DNS, or decentralized app store. The transparent mining algo does, and this is only the 1st part of BCNext's plan...

Edit: BCNext pointed out that I forgot to mention Selfish Mining. Sorry. Transparent mining solves the selfish mining issue completely. Dixi.

Let me get this straight:

Every account (call it X) in the network is able to determine which other account (call it Y) in the visible network should forge the next block, right? If Y refuses to do so, X will penalize Y as that, X won't consider Y forging the next 1440 blocks. I think I got that.
What about accounts outside of the perspective of X? They are practically not forging from the perspective of X.
There could be an account (call it Z) X have no awareness of and will get the forged block of Z via its peers. Because the peers P are trustworthy, X will only get a block from Z if Z forged a block when it was supposed to in the eyes of P. So far, so good.

What if, the peers aren't trustworthy? What if Z is only visible to its fellow peers and the peers function as a intermediate to Z?

Like in "I am sorry, I am late, but Z forged its block on time. I mean all this network latency and the intermediate nodes between Z and me. Took some time, but we finally managed to get the block to me and NOW you get it, too, my dear X."
legendary
Activity: 1176
Merit: 1134
So, finally here is my attempt at utilizing TF for this as so far it has been pretty mechanical. Assuming that the vast majority of forging is done by NXT nodes with a full set of external plugins, then within a reasonable number of blocks, the plugin will get invoked. We can use TF to see how many blocks we need to wait for the first forged block that is on a node capable of executing the external plugin! This is SUPER useful, since otherwise we would need to try to invoke the plugin, wait for error and then retry. MUCH better if we minimized errors in the first place.

Don't know what you mean by: 'we invoke the plugin'. The node that is capable of executing the plugin executes it.
The execution of a script has to be done multiple times in order to verify its output.
The script is validated by all the nodes, but the forging node needs to "send the email". We don't want to have multiple copies of the same email, even though it is not fatal. However, some plugins will have functionality that you wouldnt want to do more than once. TF allows all the nodes on the network to know which node will actually invoke the plugin and hence when they should be looking for PoP (proof of plugin) in the blockchain. By having the plugin run in a trusted framework, eg. NXTcore, proof of plugin could be as simple as verifying hash for the content of the email.

Sorry for mixing metaphors a bit in the above. It helps me to think in terms of a specific function when thinking about abstractions. Also, I am sure there are some (many?) technical issues with my proposal as it is.

My hope is that my initial proposal is close enough to the actual solution that allows us to find the perfect solution.

James
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
So, finally here is my attempt at utilizing TF for this as so far it has been pretty mechanical. Assuming that the vast majority of forging is done by NXT nodes with a full set of external plugins, then within a reasonable number of blocks, the plugin will get invoked. We can use TF to see how many blocks we need to wait for the first forged block that is on a node capable of executing the external plugin! This is SUPER useful, since otherwise we would need to try to invoke the plugin, wait for error and then retry. MUCH better if we minimized errors in the first place.

Don't know what you mean by: 'we invoke the plugin'. The node that is capable of executing the plugin executes it.
The execution of a script has to be done multiple times in order to verify its output.
legendary
Activity: 1176
Merit: 1134
If BCNext likes what you are doing, you will get added to NXT credits API!

BCNext likes every attempt to review his ideas.
I will present a proposal on NXT core change that will give NXT fundamentally more value and allow it to become platform for all types of new functionality. Like Internet protocol did.

First, I want to make sure I at least understand the current expected implementation of NXT VM (Turing scripts) as to what it is able to do. My understanding is that it will be able to access the "entire state of NXT blockchain", so aliases, AM, etc. anything that is in the blockchain, it can access. With the concept of externally pushing down into an AM any additional data needed, the input side for the NXT VM seems well covered.

It is the output side that I am concerned with. I believe as it stands now, it will be able to send NXT and save an AM. My proposal is based on this limitation. If this is all that NXT VM can do, it means that ANY OTHER side effect of NXT VM cannot be trustless nor decentralized.

For clarity, let's say "side effect" is to send and email. I choose this example as I assume it is possible to send an email using Java with little effort and jean-luc won't yell at me about making him do horrible things to the code. The NXT core email SMTP side effect, can generate a hash on the contents and recipient of the email and use that for TXID to be put into NXT email blockchain (or even main blockchain). The importance of something being in the blockchain is that it can be validated by all on the network. The importance of being implemented in the NXT core is that it is the only way for it to be able to be trusted.

So, using the above mechanism, any side effect that can be implemented into the NXT core can implement a decentralized and trustless solution that is controlled by the NXT VM script. However, one problem that I see is that there is no assurance that the NXT VM's output AM is going to be parsed properly and the NXT smtp invoked.

Without a way to assure a once and only once invocation of "side effect" that we can rely on being used, the power of NXT VM is limited to the self-enclosed NXT universe. On the other hand, if we can ensure that "side effects" that are supported by NXT core do in fact get executed, it opens up vast new possibilities. VAST!

I want to take it one step further by having a NXT-plugin architecture defined. There are just some things that even I wouldn't want shoved into the NXT core, let alone jean-luc! So, we need a way to ensure that such external plugins are executed once and only once (similar to double spend problem). I imagine that not all NXT nodes will have support for all external plugins, but as long as the NXT hubs (> 100 servers) can run these external plugins, then I believe it will work.

So, finally here is my attempt at utilizing TF for this as so far it has been pretty mechanical. Assuming that the vast majority of forging is done by NXT nodes with a full set of external plugins, then within a reasonable number of blocks, the plugin will get invoked. We can use TF to see how many blocks we need to wait for the first forged block that is on a node capable of executing the external plugin! This is SUPER useful, since otherwise we would need to try to invoke the plugin, wait for error and then retry. MUCH better if we minimized errors in the first place.

I hope this is close to what BCNext is looking for?

Generalizing, for any plugin functionality there needs to be a way to invoke it once and only once and a way to verify it on all other nodes. For hardcoded plugins, we avoid the whole verification process. If there is a way for the NXTcore to get a read only pointer to the memory space of the plugin code space, the NXT core can add a function to verify the hash of the code space to verify that it is still running an unmodified version since the published source code of that plugin. So, maybe we just need to memory map the plugin and find its code, hopefully not too hard to do. Verification that the plugin has not been modified goes a long way to preventing Evil Bob from changing the code that implements the plugin. If the plugin code cannot be changed and it is correlated to published source code, then maybe even skeptics can trust that the NXT plugins will always do what they are supposed to. [I avoid discussion of proper error handling within the plugin as that is specific to each plugin]

So, at the very least the hardcoded plugin will allow NXT VM to affect the world outside the NXT blockchain and this is the key to being able to implement DAC. If we can make NXT plugins secure and verifiable, then NXT will be the first platform that allows anybody to create new functionality that is decentralized and can operate without trust by simply defining a "side effect" and a way to verify the side effect was actually done. Combine this with Transparent Forging's ability to predict the future forging nodes, allows a subset of NXT infrastructure to perform the plugins work.

Needless to say, achieving the above will make NXT like the Internet was when the only thing you could do was email. Order of magnitude increase in the utility is probably a gross underestimate.

James
 
legendary
Activity: 2142
Merit: 1010
Newbie
So, how do we continue? You said we make it step by step.

Cryddit already showed that forging is ok - https://bitcointalksearch.org/topic/m.4861016

Err, so this thread can be closed?

EDIT: a simulation suffices?

This thread is about another thing. One guy just derailed it.

Simulation is enough, at least for me.
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
So, how do we continue? You said we make it step by step.

Cryddit already showed that forging is ok - https://bitcointalksearch.org/topic/m.4861016

Err, so this thread can be closed?

EDIT: a simulation suffices?
legendary
Activity: 2142
Merit: 1010
Newbie
So, how do we continue? You said we make it step by step.

Cryddit already showed that forging is ok - https://bitcointalksearch.org/topic/m.4861016
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
Let me think about this.

One roll of a die is a Bernoulli trail, so we should have two binomial distributions B(1000, 0.002) and B(1000, 0.001).

The expected value should be 2 and 1 respectively if I am not completely mistaken.

I think u r right.

So, how do we continue? You said we make it step by step.
legendary
Activity: 1176
Merit: 1134
If BCNext likes what you are doing, you will get added to NXT credits API!

BCNext likes every attempt to review his ideas.
If he likes "attempt" then I have attempted a LOT! Just havent felt like I truly understand it well enough to be able to analyze it, let alone develop new ideas.

My hope is that I will be able to present specific functionality that can only be properly implemented using TF. Even if I cant understand TF fully, I hope that it will spur others who do to figure out how to properly implement the new functionality.

James
Pages:
Jump to: