Topic: Creating semi-nodes to sustain the network - page 2. (Read 456 times)

I know but would be a plausible reality in the future. I agree it would undermine the basics of desentralization but it could happen never the less.
I don't know what tommorow will bring, not to mention 10-20 years from now. But the way I see it we should talk about thse types of scenarios than to be passive about them and be caught by surprise.

I see & understand what you guys mean. Thanks for the explanation - I appreciate it.

---

Holding full nodes on satellites and/or data centers would be centralizing the network, defeating Bitcoin's purpose.

bitcoin is trustless, which basically means you don't trust anybody else. instead you verify everything there is to verify from the very first block to the last.
another thing you have to keep in mind is what (i believe core calls) chainstate. when you receive a new block you have to know what outputs are still unspent so that you can verify that new block. to do that you have to have verified each block from 1 to now and have created that database. that is not something that you can trust others with. and it is not something that  you can build without downloading EVERY block.
=> that means "not downloading everything" is not an option if you want to be considered a "full node".

=> but that also means that all you need is that UTXO database and everything else is delete-able. which is what pruned mode does. it discards old blocks after they are verified so that the storage requirement is small.

with your idea when a node doesn't download a "slice" it is not capable of updating its UTXO set, now it has to "trust" a third party to update it for them. i'd say use a simple SPV client instead if you want to put trust in another node.

I see it as an "all or nothing" approach. You either use the pruned version where you see the latest blocks (case in witch you also download and verify every single block from Satoshi's basement to date and keep the prunes or keep a complete ledger for the reasons mentioned above by mocacinno.

Indeed, there is the possibility that nodes will be held in the future only in data centers and the network would rely mostly on big data companies. Who knows ?
Maybe they will launch 1000 blockstream satellites, maybe Elon installs a node on his 40.000 satellites, maybe martians come with their evolved tech and take control of all our crypto )) but trusting an almost full node somehow does not resonate well. Not much difference between that and blockchain.com ... still need trust

Interesting idea tho   

It's an interesting idear, however, it would require you to trust the other nodes.

One of the mayor reasons for running a full node is because you can verify every transaction in every block, build your own utxo db, fill your own mempool, verify every new block, check each and every transaction funding one of your address without trusting somebody else... As soon as you enter a system as described in your OP, you'd be trusting other people again.

As far as I know, the more full nodes there are on the network, the more trustless the blockchain becomes. But the large size Bitcoin's blockchain will sooner or later become a problem when it comes to users' capacity of holding an entire node on a hard drive.

I do get the idea that hard disks will increase in size in time. I mean, we see this with every new phone, PC and other devices. But I think it'd still be a good idea to somehow make it so that a larger percentage of people's devices could become at least semi-sustainers of the trustless manner of BTC.

So what if, besides pruning, using an SPV and owning a full node, we had the option to only hold 10% of the blocks on our device in combination with an SPV node? As far as I know, there's constant communication between the Core users (can't find a more specific term - I mean communication between those who are using the Core wallet), right? Well, then the blocks could be split in 10 slices and whoever chooses this option I'm suggesting would have to only store 10% (a slice) of the blocks downloaded on their device. The newly installed Core wallet would receive the information regarding which slice they should become in order to know which blocks to download and store on their device.

How would it work?
Say there were exactly 999,999 blocks mined on the network. Each of the 10 slices of semi-nodes would have 10% (so 100,000 blocks) downloaded and stored. As soon as block no. 1,000,000 is mined, the last slice (slice no. 10) gets to download it. All the other slices would delete the first downloaded block (except slice no. 1) and then download the next one after the last.

For example,

• Slice 1 (storing blocks 0 - 99,999) will download block no. 100,000.
• Slice 2 (storing blocks 100,000 - 199,999) will delete block no 100,000 (as it's now stored by slice 1) and will download block no. 200,000.
• Slice 3 (storing blocks 200,000 - 299,999) will delete block no. 200,000 (as it's now stored by slice 2) and will download block no. 300,000.
• ... and so on.

Now let's say there are 1,000 semi-nodes split into a perfect balance of 10 slices of 100 users. After a while, 300 users disconnect at the same time. Obviously, these 300 aren't split perfectly into 30 users from each slice so the balance is disrupted. What happens next? Well, the next one who downloads the Core wallet and decides to take only 10% of the blocks will download the slice that has the least users, helping maintain a balance as close to 10% as possible between all slices.

I have also made a table (forgot to complete the first row and lost the excel file) if it helps but I am not sure how easy-to-understand it is. It was a big headache as the first block is block "0" and not "1"

With a blockchain size of 500GB, a Bitcoin supporter/user could sustain the network even by downloading a slice of 10% on a 64 GB phone, hence becoming a semi-node. We could have the option to download 10, 20, 30, ..., 90% of the blockchain if we have enough storage. For example, if the blockchain had a size of 500GB, maybe I have a 256GB phone and I want to become a semi-node downloading 200GB (so 40% or 4 slices) of the block data.

Is this plausible & a good idea or is there a large flaw I'm missing?