Quote from: Rogerdale on October 16, 2017, 05:05:02 PM

Quote from: VanBreuk on October 16, 2017, 10:30:06 AM

Quote from: Rogerdale on October 15, 2017, 10:45:38 PM

Does anybody know if a bundler in a child chain has 60-70-80% or whatever high percentage in his own chain, can he successfully conduct a 51% attack?

Block generation (PoS forging) happens in the main Ardor chain only, according to ARDR stakes, so child chain token balances are not affecting chain security.

So in my wallet I would see the transaction confirmed only when it is added to a bundle and confirmed in the main Ardor chain?

In this case, what is the purpose of this mechanism with bundles, why not just confirm each transaction from each child chain in the main Ardor chain directly?

Don't think about the addition of your transaction by a bundler as a confirmation. Bundlers should be gathering transactions broadcasted in their child chain continuously, "offering" their current bundle to the main chain regularly, and the main chain will generate blocks at the network target time.

The point of bundles is scalability / prunability. You can read about the logic in https://www.jelurida.com/ardor-blockchain-platform-design :

Quote

The forging chain supports a very limited set of allowed transaction types, such as transfer of Ardor from one account to another, trading of Ardor to each of the child chain tokens and back, leasing Ardor balances to other accounts for the purpose of forging, and a special type of "ChildChainBlock" transactions. The forging power of each account depends on its Ardor balance, in exactly the same way it depends on the NXT balance in the Nxt platform, the consensus model remaining unchanged. All transactions that change Ardor balances are recorded on the forging chain, and therefore downloading and re-processing the transactions from the forging chain provides exactly the same proof-of-stake security as the current Nxt platform. But all transactions that modify child chain token balances only, or any other account holdings (such as assets or currencies), are not recorded on the forging chain, but only on their corresponding child chains. Thus, removal ("pruning") of those child chain transactions after they are no longer needed, does not affect the blockchain security, as validity of Ardor account balances can always be verified in a trustless manner by each node.

Of course, the validity of child-chain transactions and account balances (in native tokens) must also be ensured by the platform, and this is done by anchoring them to the forging chain by means of the above ChildChainBlock transactions. This special transaction type contains as an attachment a list of one or more transactions belonging to a single child chain, i.e. denominated in that child chain native token, with their execution affecting only account balances and holdings on that chain. In effect, such an attachment represents a "block" on the child chain, although no actual forging (block generation) is done on child chains. But those attachments are linked to the ChildChainBlock transaction by means of a cryptographic hash only, thus allowing the transaction signature verification to be performed even after the actual content of the attachment has been pruned after some time. This is building upon design and technology already implemented and in production use on the current Nxt platform - in the form of prunable messages, and prunable data ("data cloud"), and a network of special purpose archival nodes to store them.