I've added more description about how Eltoo can adopt this optimization.

I'm thinking of an optimization applicable to Eltoo when schnorr MuSig is available.
Please notify me if There's a significant flaw in the idea or It's already there.
The link is a document inside github. Everybody can view and edit it inside github.
https://github.com/hosseinamin/noctahub-docs/blob/master/intro.org

Edit: I assume It's not correct to leave part of the discussion outside of the forum.
Here's intro document.

* NOctaHub - Nested Hub Limited to Eight Members

NOctaHub is suppose to be an optimization on use of distributed ledgers. Bitcoin
is the first and most famous example which uses its ledger to keep track of
credit of participants currently some people are using it as money.
It uses asymmetric cryptography with a simple stack based (Forth like)
scripting language for performing transactions and change state of the ledger.

Most obvious issue in the ledgers like this is scalablility, As network
participants increases more transactions will occur on the ledger. The issue
is that all users should audit the ledger to verify the integrity of it.
With the current technologies we have the bottleneck is at communication.
And it can lead to two options. First option would be to sacrifice
distributed property of the ledger for those users whom have
lower network bandwidth. And second option is to put a limit on how much
can be written on the ledger over time (At the moment bitcoin
consensus has limited the blocksize to about 2MB every 10 minutes).

In the rest of this document I'm going to use the word bitcoin to refer
to any programmable distributed ledger.

NOctaHub has composed of two optimizations. OctaHub, And nesting hubs to
form a tree of members. Which has an exponential effect OctaHub. Nesting
these hubs four times allows up to 4096 members to exchange credit.

NOctaHub's optimizations allows users to use less space on bitcoin. The same
way lightning in bitcoin is intended to do the same. By using the scripting
features of bitcoin users can get into groups to perform changes
on their credit or any kind of data. They can keep changes to themselves and
only notify the final change to ledger. Note, Eltoo is another example of doing the
same thing more efficiently Its not yet available for use (Q1 2019).

Assuming eight parties jointly have access to a single entry on the ledger.
OctaHub's main function is to split these coins with their credit to these
parties at the event that anyone needs to leave. Either they went offline for
a long time or they just want to leave the group unilaterally. It is designed
to use the least space possible on bitcoin chain that enables this group
to divide in two or more.

I would imagine it is possible to organize parties more than eight in a nested
fashion to form a tree were all participants are at leafs. And then higher
levels are multi-sig of participants in that hierarchy.

These two optimizations can exist in two applications.
Eltoo and Traceable Timestamping. This introduction has very little
technical description. I've put some thought into using this on Eltoo. Which
i think it would be possible.

This feature requires schnorr MuSig and SIGHASH_NO_INPUT upgrade on
bitcoin network.

Why eight participant is the limit suitable for this setup? The idea is to
pre-sign a set of transactions that would be possible have a set of options
that will end up with coin-split resulting in two or more coins.
Meaning output coins may still be a multi-sig for sub-set of existing
participants. For eight participants members should at least
sign 256 transactions to have all possible options.

Simplest way to form all possible options is to think of each participants as
a bit on a byte. zeros are in group A and ones are in group B.


** How a multi-party (floating) transaction can have multiple paths?

By paths in this case i mean possible split combinations. And building on top
of them.

If we consider all paths for floating transactions do not share same public keys
when a transaction gets confirmed. It invalidates all the previous signed
transactions. In case Eltoo the confirmed tx waits until =OP_CSV= reaches.
Until then update signatures are accepted.

One thing I'm not sure about Eltoo is that at setup stage a transaction has
generated and broadcasted and participants have access to settlement tx after
that which they can broadcast at anytime. I'm wondering, If There's an exiting
multi-sig between participants in a *single coin*, Can it be considered as
ok for setup transaction?

The issue is probably related to having *sighash-single* for first tx.
Which will result in mitigating the issue with pre-defined fee for first tx.
Or using child-pays-for-parent at event of mempool congestion.

** How nesting can work on Eltoo?

Most difficult issue in this part is to figure out order of communications.
And correct control for each party.

The idea is a group of parties can own a single coin jointly. And at event of
leaving, The output coin has their own rules (inner Eltoo).

OctaHub allows any party to remove itself or others remove it. Which is crucial
when number of participants increases. This unilatiral action allows for the hub
to live on with writing only necessary split or joins on the chain.

When settlement coin of Eltoo tx is multi-sig of an entity on the formed
tree closer to leafs. It allows for parties on that coin to perform their own
update/settlement at the event when higher level Eltoo is over.

So a user in a four level deep NOctaHub can get its coin by waiting four times
the amount of regular Eltoo.

Plus side of this combination allows for inner Eltoo's to perform their updates
when all participants of that coin do exist. Even if other nodes have offline
users.

I don't think so. If the blockchain can fail (meaning if an invalid block generated. It will die for those who consider it invalid). And it requires a single entity to control the chain. It's obviously centralized. But some applications don't require it to be open and public. This doesn't mean it should be permission based.
Immutability can help multiple users make sure either blockchain will fail or confirmation goes through. Still the main chain (bitcoin) can re-org and change the history of private chain.

Edit:
By this i meant. "This doesn't mean it should be permission based." => Still that blockchain can use bitcoin's code as Its base.

By private blockchain i mean, The ownership is private. It doesn't prevent the blockchain to get validated and used by other users.

Prominent use-case of Ethereum is to create a new currency with new rules like ICO's. Decentralization is a myth remained in most discussions.

There's need for two important features in these currencies.

1. All participants should be able to validate the integrity of the ledger.
2. Ledger should be resistant to changes. Ultimate goal = immutable ledger

Instead of Ethereum I like the idea of each currency have their own blockchain with the above features.
In example of ICO's. All of them have issuer (owner). So it being public (mining/staking based) Doesn't make sense.
Also maintaining staking/mining based consensus is expensive.
Running a privately owned blockchain is the way to go.  And in this thread i did talk about how we can implement this feature in bitcoin in such a way to it would be very efficient to run (less expensive).
https://bitcointalk.org/index.php?topic=5120606.0

Inflation in national currencies help governments maintain their economy. Inflation in bitcoin may result in increase or Its security or more profit for miners.
I don't know What's good for bitcoin. But I think bitcoin being deflationary will not make much difference to world economy.

Maybe the right question is. How much security is needed?

I've researched about `SIGHASH_NOINPUT`and schnorr MuSig (n-of-n). Which will make it possible that all participants (owners) have a say in Merkle tree generated. With a small transaction.

And this Merkle tree will be used in a specific way which makes it possible for private blockchains to track and verify new blocks of those blockchains.

I don't think there's a difference. Except it will be possible to bulk multiple blockchains with one transaction per confirmation.
The main point is to reduce the load on bitcoin itself while being able to use the security it provides. Still There's a need for trusting the owner to keep the blockchain alive. But good part of it will be that the owner will not be able to double-spend without performing 51% attack on bitcoin.

This is a rough idea. I think it can be valuable.

"Private blockchain" Meaning a blockchain that's privately owned by someone. And at least private key is needed for producing new transactions for adding confirmations.

I would like to gather better technical description for it.

One of the important reasons that re-org exists in bitcoin. Is that no one would be able to kill it. By creating an invalid block at tip. This will be possbile for these private blockchains. But only one person is responsible for it. And all users can monitor it.  

I did write a small article about privately owned blockchains. https://medium.com/@hosseamin/privately-owned-distributed-ledger-why-c685b81df7d

RISC-V ISA has implemented and was developed using FPGA's. These devices are used for testing gates before taping it out as an ASIC (CPU is a programmable ASIC) .
Well these devices have several GPIO pins for communicating with other devices. One can limit amount of IO's they use and use an open-source communication method to make sure it can only do one thing.

And about verification of loaded bitstream. Best option is to build and upload the bitstream.

How much one should think ahead to break into this device?

RISCV is open-source. You can build bit-stream of it. Or even add custom instructions to it. I'm not sure how these devices store data, For storing private key.

I'm just thinking this is the correct way to do it. For most applications trust to other party is essential. With these private blockchains audit of the ledger is being done by computers (any validation program can be written. smart/non-smart ). Probably only one proof-of-work chain is affordable. We better capitalize correctly.

For example all ICO's do have an issuer. In other words ICO's have owner. So why not use a private blockchain.

Trustless doesn't make sense to me. The point is to verify validity of the ledger and also ledger should be immutable thus connecting it to pow.

FPGA can be a possible solutions for more controlled transaction signing. Since these devices are made for engineers to build chips.

I have a clever idea in my mind which enables a private individual to create a blockchain and issue tokens while accepting some consensus rules between all parties. Using bitcoin's proof-of-work and It's re-org feature as the mechanism to reach consensus.

This has nothing to do with public blockchains were nobody is in charge. Instead the blockchain has an owner and It's in their self interest to not break the consensus rules since others are monitoring them. While users do not need to trust that person to not change ledger without doing a re-org on a pow chain like bitcoin.

This is probably not a new idea. The idea is that we use the feature of traceability of coins and apply a set of rules that disables all possibilities that the other party can break the chain created without doing re-org on the main chain.

With this ability one can argue all sort of blockchains including truing complete ones can be created with owners. Which in my opinion it is a better approach for doing things Etherium does. Since there's no need to verify validity of all tokens and chains.

But in my opinion this is still expensive for each blockchain to exist by verifying the traceability within the main chain. Instead this task should get delegated and bulked inside one transaction per confirmation. Though It's not important that all blockchains use the same transaction.

The solution for bulkanizing needs schnorr signatures (MuSig) to be efficient enough and owners would not need to lose the ability to maintain their chain by themselves. Since anyone that controls the chain can simply kill it by running away. This procedure needs a moderator to maintain bulkanized tx. Since there's a chance that any participant to go offline and disrupt the process. The moderator can come up with solutions at those times with least amount of bytes needed to get into main chain.

What you guys think about it?

I want a TEST PILOT CODE

Any chance i can join?

I realized this is not going to work. re-org on sidechain is also needed. Which essentially it may obsolete merge mine in first place.
The reason is that one can create a block and don't publish the content of it. Then sidechain is dead.

I don't know about two-way-pegs. I've not thought about it.

1. The 51% attack (re-org) is already solved at main chain. My point being it should not be solved again for sidechain (merge mined).
And conflicts are solved with other means. Which i did discuss in my earlier post.

2. There should an incentive to mine blocks. Like inflation, moving BTC or other means. At the end there should be competition at inserting the new block. Still if the block is invalid it won't be added to UTXO set of sidechain. But still is added to chain of block headers.

I hope i did described it well.

I suppose it can be done in any blockchain. The security given by that blockchain will apply to the sidechain. My view is the only sensible scheme is proof-of-work. proof-of-stake does already exists. It's the traditional banking.

I want to point out that sidechain 51% attack is not a problem at the first place. Because it shouldn't be in the consensus of it.
I don't know how Rootstock works. I've just studied truthcoin. It did describe how re-org can happen in sidechain without doing re-org on main chain.

This is how sidechain should work.

1. pow is verified from main chain and re-org is possible if main chain had one
2. There should some pre-defined genesis fingerprint, This is block zero with no transaction in it
3. From there on if next block of main chain contains hash of sidechain block with hash of prevblock, Then verify the validity of block. And accept only if its valid.
4. After that any attempt to attach another block to a that prevblock would fail. even though the created block is invalid.
5. If there exist a main chain block with multiple block of the same sidechain. Accept the one with greater or less than all the others. (hash of it)

That's almost all is needed to not have re-org of sidechain and still all nodes will reach consensus.
Is there any issue in it?


Edit: This is not going to work. And here's the reason.


I realized this is not going to work. re-org on sidechain is also needed. Which essentially it may obsolete merge mine in first place.
The reason is that one can create a block and don't publish the content of it. Then sidechain is dead.

Correct. What i was talking about is re-org within a the sidechain's merge mine without the need to re-org the main chain. Which was described in here.
http://www.truthcoin.info/blog/blind-merged-mining/

I'm saying re-org structure made by @truthcoin at twitter is not a necessity.

Edit: I'm wrong here