Topic: Bitcoin Scaling Solution Without Lightning Network... - page 5. (Read 1740 times)

People,

What about something like this:

https://ibb.co/c249h0

Vertical blockchain block scaling.
Each block would have the same limit size as now.
Possibility to create many "vertical" blocks in each 10 minutes interval when Mempool size is overcharged.
Each new layer blockchain would be part of a new layer node so we could have infinite Layer Type Nodes

That Layer Type nodes will include less repeated data, so we save disk space, if we have 1 million nodes we dont need to save all information in the same nodes, thats a waste, so when someone wants to install a node, the node install program will sugest the best Layer Type node to install, the one the system needs more.
The Layer Type nodes exchange information between them, something like pruned nodes.

This way we prevent download and upload of big quantities of data like it happens with BCH with huge block sizes.

All the Layer Type Nodes share information they need that can be tested with the information that Layer Type Node already have, everything is hashed with everything.

If anyone is interested in a simpler understanding of BlockReduce, they can checkout this 30 minute intro that I presented at University of Texas Blockchain Conference.  I ultimately don't think it is all that complicated, it is really just multithreading Bitcoin and tying it back together with merge mining.

BlockReduce Presentation

In terms of issues with lightning, I think that the biggest problem is the cost of capital.  Transaction fees are necessarily going to be non-zero in economic equilibrium because node operators will need to pay for the cost of money, or opportunity cost.  Therefore, you would expect to pay ~1-4% annually of a transaction that takes place in a channel that is open for any period of time.  It will also need to account for the costs of opening and closing the channel.  The only reason that LN kinda works is because people are not fully accounting for the cost of capital needed to run the nodes. 

I think its possible to create new bitcoin core version supporting type nodes and emulating a normal node communication with old ones and new TYPE Node communication with new ones, at least with the actual block size, but that would be only experience, because without bigger blocks that is not usefull.

I suppose this thread is getting out the rails by falling into the old "To fork or not to fork? This is the question!" story, which cellard is an expert in it  
The fact is no matter how and what bitcoin whales want it to be, forks happen and sooner or later we need to have current bitcoin retired as the former legitimate chain and the community should converge on an improved version. You just can't stop evolution from happening, ok?

For now, I'm trying to save this thread, rolling back to the original technical discussion and sharing an interesting idea with you guys meanwhile, please focus:
What op proposes, as correctly have been categorized by other posters in the thread is a special version of sharding.
Although it is an open research field, it is a MUST for bitcoin. Projecting scaling problem to second layer protocols (like LN) is the worst idea because, you can't simulate bitcoin on top of bitcoin as a #2 layer, it is absurd. Going to second layer won't happen unless by giving up about some essential feature of bitcoin or at least being tolerant about centralization and censorship threats, compromising the cause.

So, this is it, our destiny, we need an scalable blockchain solution and as of now, we got just sharding.

Back to Pooya objection, it occurs when a transaction that is supposed to be processed in a partition/shard is trying to access an unspent output from another shard. I think there may be a workaround for this:

Suppose in a sharding based on transaction partitioning that uses a simple mod operation where txid mod N determines the transaction's partition number in an N shards network, we put a constraint on transactions such that wallets are highly de-incentivized/not-allowed to make a transaction from heterogeneous outputs, i.e. outputs from transactions in multiple shards.
 
Now we have this transaction tx1 with its outputs belonging to transactions that are maintained on a same shard, the problem would be to which shard the transaction itself belongs? The trick is adding a nonce field to the transaction format and make the wallet client software to perform like N/2 hashes (a very small amount of work) to find a proper nonce that makes txid mod N such that it fits to the same shard as its output. For coinbase transaction, the same measure should be taken by miners.

It looks somewhat scary, being too partitioned but I'm working on it as it looks very promising to me.

This sounds like an argument that the feelings of those who hold bitcoin because they're speculating on the price should somehow outweigh the feelings of those who hold Bitcoin because they appreciate the fundamental principles of freedom and permissionlessness.  It's an argument for the ages, certainly, but one that neither side will ever back down from.

Ideological differences are naturally going to occur and forks are going to happen.  Your desire to see higher prices isn't going to prevent that.  These are exactly the risks people should consider when they invest if all they care about is the potential profit.

Bitcoin is still very much the "Wild West of money".  Don't decide to play cowboy if you can't handle some bandits every now and then.  

Well, isn't it obvious? Ask to someone with a decent amount at stake in Bitcoin if they want to see say, their 100 BTC, crash in value because someone decided to hardfork with the same hashing algorithm, which means that you will see miners speculating with the hashrate while they can. See the recent dip in hashrate, which is the biggest loss of hashrate on adjustment time of the year:



I guarantee you that Bitcoin holders don't appreciate this bullshit. Not that they pose a systemic risk for Bitcoin, but they are annoying and slowing down the rocket.

Anyhow, the real question should be: what's the fear of starting your own altcoin if it's such a good idea, instead of constantly trying to milk 5 minutes of fame for your altcoin by forking it off Bitcoin? If your idea is so good, start it as a an actual altcoin and compete.

Hi, i think we dont need to hard-fork for implement something like the Type of nodes A,B,C,D... they could exist at same time as full-nodes, we only need to hard fork after if we want to upgrade block-size or not, because i read something other day about some solution to change block without hard forking.

But even Satoshi left the block size limit to can be changed in future and we will really need to change it, even with LN working 100% we will need to change blocksize or else 2MB will not support all transactions ONCHAIN->OFFCHAIN and vice-versa.

If we dont do that, that would be dangerous for Layer 1, who would support layer 1 nodes and mining if all the transactions would be done almost 100% in layer 2?

Satoshi said that after mining the 21 millions the miners would be supported only by transactions, what transactions if everyone only uses LN?
When you want to put money ONCHAIN the miners would ask you maybe $5000 because would be very few transactions and that transactions would need to support layer1 expenses.

Absolutely nothing is wrong with that. I would even like to say that it improves scalability potential with how you no longer have to care about another side thinking its own roadmap and implementation is the one to follow.

Remember the drama we went through before the Bcash split? They are gone and we no longer have to care about what their plans are, which is the best thing that could happen to Bitcoin.

I get it that people want to protect Bitcoin, or that they feel they have to, but if it is the unbreakable powerhouse people say it is, then why worry about what's going to happen? Let the economy do its work.

Most forks will fail anyway because they won't be backed by any noteworthy players. There won't be a second Bcash. We've seen the worst.

What's this fear of having 2 coins? We already have hundreds of coins, most of them being more or less hard forks off of BTC. The free market will decide which coins persists and which coins go by the wayside. BTC has already demonstrated over and over again that it is the honey badger. If we honestly have faith that BTC is anti-fragile, pesky minority coins are nothing but a mere nuisance.

You can't really know if "the vast majority of the network" is on the same page or not until the D day actually comes. We have already seen miners voting supposed "intention" to support something with their hashrate, then when the day come some of then backpeddle. You would also need all exchanges on board. And ultimately you would need all whales on board, and many of them may not bother to say their opinion at all, then the day of the fork comes and you see an huge dump on your forked coin.

You basically need 100% consensus for a hardfork to be a success and not end up with 2 coins, and I don't see how this is even possible ever when a project gets as big as Bitcoin is (I mean it's still small in the grand scheme of things, but open source software development/network effect wise, it's big enough to not be able to ever hardfork seamlessly again. Maybe im wrong and there is a consensus in the future for a hardfork, but again I don't see how.

Looks like no one remember about transaction compression (reduce transaction size). This is similar scenario with internet scaling in past where people only focus on increasing bandwidth rather than compress the content and compression format such as MP3 solve many problem (including internet scaling a bit).

IMO, bitcoin need all of it (n-layer network, higher block size limit and lower transaction size) to be able to scale without lots of security/decentralization trade-off.

     Unlike, BCH, the BTC network already has consensus mechanisms in place that they are willing to use in order to ensure the vast majority of the network is on the same page before proceeding. As demonstrated by the UASF, we can also implement ways to ensure the miners can be persuaded to go along with the wishes of the non-mining users. If someone doesn't want to wait for a high consensus in order to implement their "improvements," they are free to go fork off. That's why we already have hundreds of alt coins right now. As I have already acknowledged, the "bigger block" solution probably won't be practical for at least a decade or so. I have also acknowledged that the second layer solution would probably end up being more efficient with the resources. However, it is nice to know that there is a plan "B" to the scaling solution, just in case the problems with the LN cannot be overcome.

The main problem is that most of these scaling solutions that are being proposed will first require a hardfork. This means we'll have the drama of 2 competing bitcoins trying to claim that they are the real one (see the BCash ABC vs BCash SV ongoing war right now). This will not end well. Without consensus we will just end up with 2 bitcoins which are in sum of lesser value than before the hardfork happened.

Most bitcoin whales don't support any of the proposed scaling solutions so far so your scaling fork will end up dumped by tons of coins.

     First off, it would be nice if you quoted enough of my text to keep it in context...


     I've already acknowledged this isn't practical, right now. However, unless technology has somehow reached it's limits, it may be feasible in a decade or so. Also, in order to combat "spam," miners already have the option to not include transactions below a certain fee. They can make it very expensive for someone to try and spam the network. Also, with bigger blocks, it probably won't be worth the waste of resources for a miner to attempt to drive up the fee market by including spam in their blocks.
    Furthermore, in another thread, Greg Maxwell himself has acknowledged that a pruned node is a full node. There is really no need for every single full node to also store the entire blockchain, permanently. There are sufficient entities out there like exchanges, large pools, and hardware wallet providers, who would probably want to store the entire blockchain. I think the number of nodes that would run "archival" nodes would be of sufficient number to have the network remain decentralized.   
   I also acknowledge in my original post that a second layer solution will always end up using less resources. However, the current LN carries large risks of someone losing their funds due to either system errors or human error. I'm certainly not going to hang my hat on the LN until the developers and network itself can show results that are acceptable. Right now, I wouldn't store 1 sat in a channel on the Lightning Network. The risk of losing funds is just too high.

That particular blocks are the blocks that contain information you are trying to find like the movements for specific address transactions.

4 Types of nodes is not static thing, as the block size increase the number of splited parts increase too, we can have Type A,B,C,D,E,F and so on to keep the size of each block data in only 2MB for each node type.

Each Type of node would have 100% of his 50% so could be a seed, but if you want you can call it peer.

Look this simple logic, if you have 1 million nodes this moment, you think it would be logic to have 1 million of full nodes running?
For me that would be a complete waste of resources and for sure more safety to put some node in the moon!

Its like storjcoin service, for sure they calculate a safety limit of backups around all the world to have redundance and dont have more backups than the reasonable.

About validation/verification, i think could be done a way to each Type of node validates/verifies his part of data.

Doesn't make sense to me, if the result is the same for 4 nodes but only for particular blocks, that proves only that these nodes share the same on those particular blocks, but unless your node has verified every block once, there's no way to prove integrity by this random checking.

And besides, in P2P file sharing, a seed technically is a peer with 100% of the files. You're not seeding until you have the full file, anything less than 100% just makes you a peer

Pruning already works for size concern also?

Yeah, something like that, we will ask only the data of the blocks we need and we can test is integrity by checksum or simply by asking the same information to other Type B node randomly, if the result is the same for 2, 3 or 4 other nodes that proves integrity.

I cant see other way of shrinking blockchain sizes and this technique is like P2P file sharing, each seed dont need to have all file since there would be sufficient trusted seeds in the network with some % of the file that alltogether have whole information.

Its genius, i am Satoshi 

I assumed it was meant as a partial SPV setup.  Each type of node would be 50% SPV.  But yeah, it's not something that most users would be interested in pursuing as a concept.

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.