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 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?

[Initial goal, speeding up bitcoin initial validation time based on number of available cores]

Initial goal, speeding up bitcoin initial validation time based on number of available cores

Assuming bandwidth is not an issue for initial validation, I have a project in my mind to do this initially. And in future it lowers one aspect of scaling hurdles which is processing time for validation.

To achieve higher performance we need to expand the number of cores.
GPUs provide more cores, I think at the moment Nvidia has about 50 compute unit. Also it's cheap at the moment because of all these mining rigs.
And one can achieve even more performance by designing an SoC designed for search and cryptography operation. https://www.sifive.com/

At the moment bitcoin-core validation is taking place in a linear fashion. within a single core.

Here's what I'm thinking.

1. Implementing a new bitcoin specific con-current functional search engine

For validation, UTXO database is required. Which is a list of unspent coins. The search engine only requires to have integer for indexing and storing binary data for txid, public script and vout.
Simple sketch of it would be.
It should divide indexed data in multiple files within a range of integer associated with them. Which allows for each piece to work independently.
And fetch process can be done in bulk.
Write procedures are done periodically as re-write of indexed data.

2. Queue/Merge based managing core

I believe the best way to manage validation is to do each task in functional manner and manage it with putting tasks in queue and merging the result.
So for example when manage core receives a block, It holds state of each transaction and digest the block into input coins. And sends tasks to search and then validates coins with spending script then merges the result.

3. Passive block validation

Meaning validation will get into queue without the need for the previous block finish its job. By validating pow before doing this task, DoS attack won't be an issue.
In this form validation process are done asynchronously. Then final decision is taken by merging the result.


Let me know if you have any questions.
I'm looking for a method to fund this project. As i don't have enough capital to do it myself.

I'm not just talking about bitcoin as currency.

Here are two problems.

- Lack of Intrinsic value
- High fees due to block-size limit

Okay here's how i think it can achieve that.
 
1. All tx should burn some coin depending on tx size, (One(satoshi) coin will be equal to one byte) to put the tx in blockchain (cost of usage).
2. Subsidy should be inflationary due to burn of coins at usage. also it will define limit of blockchain size

Also this kind of bitcoin can also be used as public and open data store (what cool boys call it public cloud).

Then delivery of data can be a tool for earning revenue from consumer (ISP are doing it, but it will be cheaper for them) or the other way around.

What do you think?