Switch to ArdorForum

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)

Quote from: stdset on October 29, 2016, 07:37:04 am

And NXT won't become an Ardor childchain? NXT remains intact, Ardor/Ignis is just a spin-off coin?

Nxt remains intact, yes.
Ardor is..... a spin-off coin? I wouldn't call it that.
Ignis is the first child chain on Ardor (with Nxt's current features + more).

I really think you should re-read the OP and
https://nxtforum.org/core-development-announcements/nxt-2-0-overview/   

Not sure how Ethereum's struggles has to be beneficial to NXT.

It was discussed way too much here: https://nxtforum.org/core-development-discussion/nxt-2-0-design/
Your concerns were expressed as well.

forging and securing other child chains.

When nodes download the blockchain they greedily process all chains they see. If there is a fork at height N, they choose the chain that has better difficulty at height N+720, and abandon the other chain. They don't care about the final difficulty of each chain, they only care about the difficulty 720 blocks after the fork.

I consider four actors in this scenario. A is the attacker, E is the exchange, O is an account online during the attack, F is an account offline during the attack.
Assume that when the attack starts the account balance of A is 0 while the balance of E is 100. Neglect for simplicity transaction fees.
When A starts to attack the blockchain, it creates this sequence of transactions:

TX1  A <- E  True Bal. A=10 stored in Block N
TX2  A <- E  True Bal. A= 0  stored in Block N+1  and so on

In this simple model, after 20 transactions balances have not changed, while in the same account in the secret fork the value is 100. At that point, assume that the stake stolen by A is large enough to create a fork that can disrupt the overall system.
According to the new forked chain, E is the loser, A the winner, while O and F have to decide which chain to join. If this is the model, then A can perform an attack only after block N+20.
If this is the case, then I assume that up until Block n+20 O remains with the honest block chain since A can not rewrite the history of the chain before having stolen the funds. When A presents the new chain, O can safely decide to support the honest block chain since the blocks that justify the stake of A are not consistent with the known evolution of the chain. If O decides to remain with the honest chain, then its transactions can convey this choice by a hash that shows the chain O is in.

The real problem is F. When F goes online after the attack is complete, it finds two forks, the one presented by A "stronger".

However, another source of information available to F is provided by other nodes that have remained online and keep producing transactions linked by a hash to the honest and apparently "weaker" chain.
Is this scenario a correct description of the attack vector you are proposing?
In this case, there could be some information that can be extracted a pattern analysis of the block chain and from the (full) nodes that have remained online during the attack providing continuity to the environment.

O can safely decide to support the honest block chain since the blocks that justify the stake of A are not consistent with the known evolution of the chain.

However, another source of information available to F is provided by other nodes that have remained online and keep producing transactions linked by a hash to the honest and apparently "weaker" chain.