Bitcoin Forum

Hello,

As you can see here : https://blockchain.info/charts/blocks-size?timespan=all, blockchain size is growing exponentially.

Is it likely, that in few decade or centuries, blockchain size will be to big to be kept in any hardware node?

thanks

UPDATE ON YOUR REPLIES

1- BTC blockchain is not growing exponentially but linearly (but is still growing) This still can be discussed as blocksize increases by time.
2- BTC blockchain size shouldn't be an issue as storage capacity are high and will become even higher in future
3- The main issue is block size which if it become bigger and bigger, will not be able to be downloaded quickly enough by all nodes if the connection speed of those nodes is not high enough 

The current block size is 1Mb, so theoretically, the blockchain size could potentially grow up to 144Mb/day.
The reason why the graph looks like it's growing exponentially is because in the past, the blocks weren't filled completely.

If the block size would be increased to, let's say, 2 Mb, The graph would indicate that the size could theoretically grow 288Mb/day, but with a fixed blocksize, it would never grow exponentially. This size increase used to be a big discussion topic, altough nowadays, it seems like it's cooled down a bit. There are also initiatives like the lightning network to reduce the pressure created by the fact that the blocks are full most of the time and lots of transactions remain unconfirmed in the mempool.

It is possible the blockchain will become to big for a standard Hard disk, but don't forget, the size of the available harddisk also increases as time goes on... So, in all probability, there won't be a problem :)

At the moment, the size is ~100Gb, if the blocksize remains the same and all blocks are filled from now on, we can expect a blockchain size of ~625Gb in 10 Years... Current desktop PC's either have smaller SSD's, or larger but slower SATA disks... In my country, it seems like the SATA disk size of most new PC's is already 1 or 2 Tb, so this disk should be sufficient even in 10 years.

Blockchain size is only around 100 gb right now and in most of the countries internet speed have been increased  over the last few years and i am quite sure within next few years it may not take more than 1 minute to download 100 gb (5G technology) so downloading blockchain to run node may not be big problem also cost of hard disk have dropped significantly and even a small pendrive can store more than 100 gb this days.

It is not a problem that we should we be concerned of. In the future new technology will be used to cater the expanding blockchain size. Technology is moving fast and such problem in the blockchain will be considered peanuts later. Sometime ago the main problem was the speed but now many advancement is made t solve the issue on slow bitcoin transaction.

ill keep this short

https://i.imgur.com/X7RM3x3.png

the red line is the OP's view of the future.

the blue area is the reality of past present and future

it is not exponentially it is linearly, and there is a big difference.

and the size, although is scary at first look, is not a very big issue. it is not the year 2000 :)
nowadays you can get a very huge amount of disk space in a very small device, and HDDs are becoming cheaper and bigger. I am sure franky1 is going to come here and give you the picture of that disk on a finger tip, which you can find yourself and it is cheap.

Blocks will always be full. When we raise it to 2mb, blocks will quickly fill up. Etc. There is no ending in the block size being full. But that is good news, just means the network is being used, if they weren't full that would be a problem. If we want to have a big amount of free blocks, it would mean the blocksize would need to be too big to keep the network decentralized.

Satoshi put limit in 1 mb not just for fun. He was a wise man. We must not increase this value. SegWit and Lightning is only possible way to evolve. Fuck this dough head Roger Ver

I dont think there is any thing to worry about the size of blockchain beacuse right now the the whole blockchain can be stored on this
http://www.joebuy.com/bmz_cache/d/db7888c443a3e72d5191d01b1c03c240.image.128x128.jpg
so its safe to say that in future even if blockchain reaches the size of 1TB we would have no problem about storage.

not quite.

when the consensus is reached to go to say 2mb block buffer (acceptable limit of nodes)
pools will then say the maximum they will ever make is 2mb.. but
here is the kicker
pools will dip thir toe in the water by making a block that is just a tad bit more than 1mb. say 1.001mb just to see the orphan risks and also to see if any bugs pop up.. such as the 500kb bug Sipa introduced in 2013..

if the orphan rate is not noticeable and no drama is caused, the pools will test a little more.

this is the safe rational and natural path to do.

but dont worry about bottlenecking. they wont take 8 years to get to the 2mb 'full' limit. the progress to 2mb will be sooner.

eg if they stepped up by an extra 10kb per block. they could get to 2mb 'full' in just 3 days, safely evaluating the orphan bug risks
or if actual transaction demand per block was only 1.2mb to get everyone in.. it can have blocks have the 2mb limit but blocks only with 1.2mb due to demand only needing 1.2mb and slowly grow as demand grows.

its not a straight near vertical line like the op thinks.. its a curve

you have cabin fever. your reading prepared scripts from a group of people that want centralisation and commercial services to own bitcoin.

If blockchain reaches huge size. We lost decentralization. Only few people would run full node and control blockchain. This is what unlimited is supposed to do.

You think you're smarter than Satoshi? Well go create your alt with unlimited block size and we will see  ;D...

think rationally..
natural scaled and copable growth has been halted using fears of "gigabyte blocks by midnight" fake scare doomsday propaganda.

the simple fact is. if a node cant cope with a larger size they wont set their dynamic setting above what they can cope with. and if the majority of nodes cant cope it wont change. and pools that try to force it will just get their attempt orphaned.

learn consensus, it will help you.

even core have publicly said 8mb is safe but they prefer 4mb.. to be ultra safe.. so no actual reason to hold the base block at 1mb

getting to 2mb or 4mb or 8mb is not going to be an overnight thing. its going to be a risk averting curve that naturally progresses over time.

stop reading the fake doomsdays of 1gb blocks by midnight. as an excuse to stop rational smaller growth over natural and rational time.

they are scaring you with wild numbers, because they dont want you knowing that rational and natural numbers can work. they want to halt natural and rational growth to force you into commercialised LN Hubs so they can repay their $90m debt from investors.
they care less about bitcoin and only care about their investment contract,

just look beyond the doomsday rhetoric told to you by the guys devoted to blockstream and look for the truth behind their propaganda
.. but i guess like all the other blockstream sheep. you wont research it. you will just "trust" them on face value.

here is the blockstream rhetoric simplified.
"dont think about the blue line or choose the blue line because we want to scare you with a fake red line to push people into a new network that has commercialised hubs"

These are the same sorts of arguments that have been made for decades about the internet! usually by people who just cant see past the present reality.  like seriously are do you actually believe we will need to worry about blockchain size in a few decades?  and i doubt in centuries the concept of money will even be challenged..... ::)

How is it linear?

Linear growth means that it grows by the same amount in each time step.

Try to compare blockchain size at the end of each calendar year and let us know what you found.

No, today they increase block size, tomorrow they increase total amount of bitcoins, actually they've already promised >:(. We must stop these sneaks and not allow to increase block size by any means necessary.

lol
actually its the blockstream crew that want to increase the units of measure.. as part of their LN strategy of millisatoshi's.
look beyond what has been spoonfed to you and research

but back to the blocksize..
blockstream want to halt tx counts. at 1mb.. but bloat the DATA TRANSMITTED beyond 1mb.
they as a fake gesture suggest their new 'weight' buzzword as part of segwit allows 2.1x transactions. but as fast as people switch to segwit keypairs blockstream are bloating up transactions with CLTV bytes of data and CSV bytes of data and confidential commitment kilobytes of data.

so a one time hope of 2500tx/block->4500tx/block.. soon goes back down to 2500tx/block once they add the features.. but the DATA TRANSMITTED goes up to 4mb/block

EG 2500tx:1mb      to    4500tx:2.1mb   <-blockstream (2017)
EG 4500tx:2.1mb   to    2500tx:4mb   <-blockstream (2019)

EG 2500tx:1mb    to      5000tx:2mb   <-community desire (2017)
EG 5000tx:2mb    to     10000tx:4mb   <-community desire (2019)

Blockchain size right now is 6073 MB, and will be much larger on the next year because of the bitcoin population is growing larger and larger every day. Expect that in the next year, blockchain would be larger than it's size right now since the bitcoin population is rapidly growing each day that passed by because bitcoin really helps people in many ways.

du -sh ~/.bitcoin/
117G    /home/[snip]/.bitcoin/

Where did you get the number 6073 Mb if i might ask? Maybe you've got a pruned blockchain?

Btw: the size of the blockchain has nothing to do with how many people use bitcoin, and everything to do with the size and number of transactions.

You don't understand the concept behind LN and Segwit, or  intentionally trying to mislead others...

you dont understand it

segwit takes out bytes from tx data (the signature is moved), this is a temporary one time 'gesture' and only increases tx count if people move funds and use segwit keys.

but later more bytes are added to tx data.

have you even looked at how many extra bytes are needed for:
CLTV
CSV
Confidential commitments

go find that out.

ill give you a hint confidential commitments are said to be (by blockstream devs themselves) around a kilobyte.
yep they want to bloat an average tx of 450bytes to be near 1.5kb for the same 2input 2output tx

like i said.
segwit temporarily makes an average 450tx 'look like' ~230bytes being counted in the base block with the rest in the 'witness area'(still totalling 450byte TRANSMITTED)

but then LN has their features. which increase the base block txdata ABOVE ~230 (thus reducing possible tx's in the base block again)

and other blockstream features add on, will add about a kilobyte.. (once confidential payments and other features is added)

go research

Satoshi did not set this limit in stone.
Let me quote satoshi (https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366) (from October 4, 2010) for you:
This was more than 6 years ago, and full blocks have been limiting transactions for approximately a year.

Ontopic: at current growth, Blockchain is no limitation for a modern hard drive. Disk space increases exponentially, Blockchain only has linear growth. Even if blocks would get bigger, disk space can keep up for the coming years.
That being said, my current laptop will run out of space in about a year. I might upgrade, or prune by then.

ok imagine this is a ~450bye tx
*********************************************

input
signature
output

each star represents 10bytes for easy display

if you done the same tx but using segwit p2wpkh keys, the transaction looks like this
*********************************************

one thing that will blow your mind. the blue and red stars(bytes) are still transmitted physically. but at code interpretation level they are not 'counted' as going towards what goes into the base block.

but because at code level an opcode is used to flag old nodes to ignore data after purple. making it look like an anyonecanspend

the other stars (blue, red) are only looked at by new nodes.
  old nodes see:*********************************************  grey is ignored
new nodes see:*********************************************

while unconfirmed
old nodes wont morally relay or add a segwit tx and instead drop it. however a malicious actor can tweak their code to relay/force it into a oldblock. (hence why wpkh wallet key generation is not released pre activation to avoid malicious attacks)

after feature activation,
because only purple stars are counted (yet more stars are actually transmitted). this trick can allow more transactions into the base block
because they have room for 100,000stars (1mb)

so where say 2222tx's was 100k(1mb) stars. if everyone used segwit keys. becomes ~50k stars(~50%), giving ~50k(~50%) spare room in the block for more transactions
but remember the blue and red is still real data but just not 'counted' by the baseblock

this allows ~5000tx's(depending on ins and out and how many people use segwit keys) into the baseblock but the reality is the actual data transmitted is 2mb even with the baseblock still limited to 1mb

P.S whats said above should be interpretted by the concept. i used rough numbers for demo purposes. dont get knitpicky about the numbers. just learn then concept of HOW the switch around is used and HOW things are 'counted' or 'ignored' by nodes.. and HOW it differs to actual data transmitted

then look at the extra bytes added later when extra features are added.. and have a nice day

I don't think the blockchain size will become an actual problem with regards to hard drive size. But I think it might become a problem with regards to download speed.

People with poor data rate won't be able to ever downlaod the chain completely because its growing too fast. This will lead to a decrease in number of full nodes. The HDD isn't the bottleneck with this.

I have confidence that solutions will be found in the future for problems we're beginning to expect now. Look at how quickly hard drives/solid state drives are progressing. These days you can get a 128 GB USB 3.0 for $25, so if nothing else changes to make blockchain more efficient (which is unlikely), developments in hard drive capacity should keep up.

you dont hear millions of people uploading livestreams complaining
you dont hear millions of online gamers complaining

you dont hear millions of people facetiming complaining.
you dont hear millions of people netflix viewing complaining.

yet fake doomsdays of 1gb by midnight is used to scare 5600 people.....!!!

rational 2mb soon 4mb later and growing when node users set a setting to show what they CAN COPE WITH, to grow at a capable acceptable and no issue rate.

..

"shout 1gb to make people fear 2-8mb" <- standard blockstream script
"shout alien invasion to make people fear an ant entering your house" <- standard blockstream mindset

..

also telecommunications company both landline and cellular have a five year plan. its called Fibre cable, and 5G cellular.

so by the time we get to 8mb (in years!) the speed of internet for average users will be much better than today.
after all we are not using dialup like 20 years ago.

ill emphasise it again

getting to 8mb in years..  not 1gb by midnight.
be rational, think logical, research realistically

That is not exponential, that is linear growth.

Dont be dumb and learn the difference. The blockchain size growth is capped to 144mb/day.

Exponential growth means that it doubles every day, but clearly that is not what happens, it grows at a constant rate.

And the storage cost is shrinking faster than the blockchain size growth, so that is not an issue.

Perhaps because none of those things come even remotely close to 1 terabyte a month worth of uploading (which a stock Bitcoin node will happily do)?

If you are going to make comparisons to justify your position, at least make decent ones.

1tb a month lol

ok.. uploading. 8gb/month to send live relay of tx's and new blocks. per connection

for instance.
100 connections to fully synced node requires 800gb
10 connections to fully synced node requires 80gb

as for helping other nodes sync. that is the killer data wise.

100 connections to 0 synced node(where your its only seed) requires 9.88tb  (yea doom)
10 connections to 0 synced node(where your its only seed) requires 988gb  (yea doom)
1 connections to 0 synced node(where your its only seed) requires 98.8gb  (manageable)

the solution.
dont have 100connections..
reduce the connections= reduce the data needed to upload.
especially dont connect to nodes that are not near/already synced.. thats the main trick.

to emphasise this point..
if 75 nodes had 75 connections 5625nodes would get the data in 1 relay.
so anything over 80 is overkill/not required.

i can safely assume atleast 75 people have good internet. so not all 5600 nodes need to upload to that many. as the recipient probably already got the data via someone elses node. so if bandwidth is an issue.. bring your connections down. dont act like a 'supernode' if you are only an average node.

this is also why blockstream are doing their 'fibre' (supernodes) so that they get the data out in one relay so that other nodes dont have to do all the work.. which means you can happily play '6 degrees of separation' with 6connections(48gb) just to relay tx data and blocks so the nod can get second opinions from other sources.

Excellent point! We MUST act now so that Bitcoin's blockchain will be robust centuries down the road. We MUST stop this small-size blockchain madness here and now else we're all doomed. At least that's what I would pen if I were participating in a paid sig campaign so to up my post count.

thanks

PS: I love the wew!

update of my previous post which had graphical description of growth..

here is blockstreams Sheep (in red) impression of what they want to tell the world will happen if blockstream doesnt start its commercial service
"1gb blocks by midnight"

vs

my opinion (in blue) of onchain natural dynamic scaling over the next 33 years

https://i.imgur.com/O0nokw5.png

UPDATE ON YOUR REPLIES

1- BTC blockchain is not growing exponentially but linearly (but is still growing) This still can be discussed as blocksize increases by time.
2- BTC blockchain size shouldn't be an issue as storage capacity are high and will become even higher in future
3- The main issue is block size which if it become bigger and bigger, will not be able to be downloaded quickly enough by all nodes if the connection speed of those nodes is not high enough

referring to 3

the last time i installed a full wallet the download of the zipped block chain archive was a short download, but the amount of time it took the wallet to import the archive was nearly as long as it would have been to just let the wallet sync via linear download

this is the only time is using bitcoin when there is a huge issue because the the size.  i think it is just going to get to the point when fewer and fewer people choose that type of wallet.  someone intentionally setting up a full node will have to deal with it

OK, let's settle this:

https://blockchain.info/charts/blocks-size?timespan=all


31 Dec 2012: 4.3 gb
31 Dec 2013: 13.4 gb (+9.1 gb; grew by x3.1)
31 Dec 2014: 27.8 gb (+14.4 gb; grew by x2.1)
31 Dec 2015: 53.6 gb (+25.8 gb; grew by x1.9)
31 Dec 2016: 96.2 gb (+42.6 gb; grew by x1.8 )

So far, as per above data, it's definitely more appropriate to say the growth was exponential, not linear. With the capped block-size the trend should change though.

referring to your frustration of setting up a full node.

the reason your frustrated and many people are. is that while its setting up its not really 'usable' straight away, you cant see current balance and cant really spend anything until its synced..

right, thats the main frustration.

this can be solved so easily.

if the devs just got their implementation to not sync first then check unspents(utxo) second.. but instead grabbed some litewallet code that grabs unspent's data from other nodes first. and then done syncing second. the syncing then becomes just a background/unnoticeable thing. while the node is actually functional straight away.

bam!. easy to code, lets users just get on with using bitcoin straight away. problem solved

EG emulate electrum or other litewallets as soon as you open the node. then syncing is not a critical, thumb twiddling wait. its just a background function users dont realise is happening, because they are no longer forced to wait until synced before properly using it

as for the exponential vs linear.. its neither.

its not linear (straight diagonal line)

its not exponential (horizontal that curves vertically)

it IS an S-curve..


the issue is that we are still in the early days of bitcoin so we are still at the bottom section of the S-curve, so it appears like its exponential

only problem is that growth has been halted to not see the bigger picture

i personnally am not bothered by the wait, i was just stating that, as of this moment, the only issue created by block chain size is the initial setup of full wallet, by this i am implying that there is no problem, as not many people need that full node on their pc.  those that want to run the node should expect some time to be used.  you want to start a new domain, you expect a possible 24 wait for DNS propagation.  technical aspects to all project take longer than the standard use version

and my reply was that you can have the cake and eat it.

rather than having the implementation useless until syncing. thus holding people up and the sync becomes not discrete and noticable enough to frustrate

you can be a full node and not have to wait. simply by devs releasing a implementation that emulates a litenode instantly while it discretely syncs in the background, unnoticed because its no longer a hindrance to utility.

for me, as a trader and wallet holder, several wallet types without the need for a download are fine.  the reason for me ever setting up a wallet deeper than that is because i am going to do some major work in bitcoin. at a bare minimum, i am choosing the run a node and help the network, on the other end of the spectrum, I might be manually constructing transactions via cli.  When i am going to work within the network, i am not just not bothered by the setup time, i want that full block chain.  what you are talking about is great for many people, but to me it is like starting a painting with only red paint because i am too impatient to wait for all the colors to arrive.  getting around a full block chain sync is bypassing some of the security of the ledger and i see no reason to do that.  if i need an immediate solution and a full wallet, i will simply download electrum and the official bitcoin core and use electrum while the other syncs

what im saying is you get the cake and eat it.. imagine it as electrum and core combined.. a hybrid.. but the extra advantage of not neding electrums central server

that way your still waiting for all the colors of the painting to download. but your not having to wait for red to download at the end because its given to you at the start.

thus not needing 2 wallets
thus not needing to copy and paste privkeys from one to the other. or spending the funds of one wallet to move it across.. its all one and the same

it also wont rely on a electrum server.. it would download the color red from other full nodes on the network like it does with syncing. so it becomes better than electrum by not relying on electrums central server.. simply by downloading red first. rather than waiting to collate the data to get red last

just saying that i have no issue that both options are there in different forms.  i see no reason to break a working system in an effort to reduce the number of tools i can use from two to one.  if i needed ten versions of the bitcoin wallet and you said recoding and compiling would reduce me from ten tools to one, awesome.  bitcoin gets enough people under the hood playing around and i see no major problem that requires repair

Trades should learn the habit to download the entire blockchain and store coins locally. Yes, you may not worry about altcoins, as a trader you will likely not hold altcoins long term, but your main stack of bitcoins should be held locally un bitcoin core's wallet, everything else is just not as safe.

very true, and i am willing to wait a day of two for a secure wallet for storage.  and if i am intending to deposit coins into that wallet to keep them safe, i do not want to try to monkey around the download time at the risk of being any less than 100% secure

like i said.. by downloading red first instead of last. your getting that
the wallet is local. the data is not coming from a central server but from the same diverse nodes. its just downloading the red color first instead of last.

ok, let me say that i am not disagreeing with your idea, simply saying i personally do not need it.  if the demand for such changes becomes great enough, you or someone else will make it happen.  it is not a bad idea, simply one that i do not need to take advantage of.

im not saying you personally need it. but you raised a point


and i informed you that its not actually an issue that cannot be solved in a few lines of code.. because it can be solved with just a few lines of code

Even though storage media are also growing linear to block size increases, you will still find that most average computer users will not be able to

sacrifice hard disk space to store the Blockchain. Most of the people I know, have on average 3TB storage capacity. { Eg. 1 TB for OS & Apps and

2 TB on external hard drives for data archiving or backups } Most of these users are power users, and I expect the average computer user will only

have a 500GB to 1TB hard drive, so sacrificing 120GB+ to store the Blockchain, would be a big ask for them.  ::)

i have never thought of it or tried, but in some situations, like a small office, could multiple users share the same block chain file.  say, three users on separate pc's each with their own wallet.date file, but the actual downloaded block chain data in a central network share.  there may be "file in use" errors kicked back at times like a block update, but the internal block update function in their wallet core could be used to stagger the wallets accessing the file, wallet one goes straight there, the block update fires a busy program that delays wallet two from updating and so on. 

If this is possible, then most people could, even by themselves, download the chain once, store the file on a separate drive and access it as a network share and auto backup the wallet.dat to the shared directory.  then, a full bore computer crash would only mean downloading the fresh wallet software and moving the backed wallet.dat file in and pointing the wallet to the block chain data file

Bitcoin Core is not currently written to support this.  It would be possible to do if someone wanted to put the effort into writing the code.  There is nothing in the protocol that prevents this.

Another option would be to run a single server as a full node with the ability to connect to other full nodes on the internet.  You could then store regular backups of the blockchain on this full node server. Have the other computers on the same network fire-walled so that they can ONLY connect to the local full node server.  All these other computers could all have pruning turned on so that they don't store the most recent blocks from the blockchain.  Bitcoin Core already supports this setup.

this is like saying
World of warcraft or Call of duty should not make another release because each release adds another 60gb of data to a hard drive each year..

halting 5600 interested and active people that want to be nodes, with speculation about what they may or may not want is foolish

blockstream done this foolish attempt in 2015. '2mb is bad because increasing the possible bloat of 52gb a year to 104gb a year is a big ask...'
but now blockstream are suddenly happy with 4mb because they need 3mb of weight area to fit in their clunky confidential payments feature in the near future.

strange isnt it... how they suddenly stop doomsdaying 'little people cant handle 2mb' the very second they realise their own features require 4mb weight blocks

that would work well for a small network that actually used multiple users, but is a little much as a simple backup area.  i tempted to puruse the code and find where the daemon declares the location of the file, but that would just piss me off. even a tiny simple code change and backups files or not, i have forked and live in my own little bitcoin world

EDIT:I will look it up later and have a thought.  Not sure if Windows has a like function, but Linux can use symbolic links, i wonder if when the code names the bootstrap file if I could somehow create a symbolic link with the same file name.  got a few things to look up

cant you just have a bitcoin node set up to be an electrum server. and the the other users in your intranet, just use electrum to connect to your 'server'

other people have already got other local wallet systems that API call specific servers to grab the unspent data required to locally make a tx on their own system away from the 'server'

..

may i ask why do you want to have a 'full node' that doesnt have its own full dataset..
is it so you can sybil attack by having hundreds of 'full nodes' appearing on the network but only having one data store or is there a specific reason for requiring a fullnode without having the data locally.

Ok, stupid is as stupid does.  the purpose of doing all this was to not have to download a wallet, the block chain and wait for sync as a full node if the PC crashes.  the idea was to store the block chain and wallet file on a second hard drive and try to force a software wallet to use those.  the real solution is much simpler.  the wallet software and all its files will reside on the second hard drive.  if your primary drive data gets lost or destroyed, you restore the OS to the primary hard drive and the second drive's data is still untouched.  Use a desktop link to the wallet exe as either a simple shortcut or as a network link, whatever. using software or a simple script have the wallet.dat file copy to a backup location.

addmenum:franky posted as i was posting this and his question was pretty much answered here.  we do a lot of technical playing with bitcoin core and the issue was the fact that everytime there is a computer crash, the block chain and the synced data is gone. 

So could something like this be one way to solve the issue of node count that the community has expressed concern over recently?

I'm not well versed in what happens when you run a node and how a lot of the technical aspects affect other portions, but this could be one way to maintain node numbers in my opinion, assuming that you can take the blockchain from the node and sync it to the wallet.

what i am calling a full node is not the correct term.  a full installation of bitcoin core will(after downloading and syncing and all that) will start the wallet software and the GUI upon start up.  almost every normal user can operate like that. you have the ability to use the GUI to perform all functions and can also use the CLI functions from the command line(that is what we have to have).  there are various ways to tell the core to act as a server and this activates the daemon or server.  that is a full node.  your software is performing three functions as a full node, the wallet, the server and the in between parsing of data and commands and what not that make the real bitcoin software do something when you click the GUI

a full node is simply the core running everything and announcing to the network that it is there.  do not confuse this with generation or hash mining. 

---my reply below is about an earlier concept that deals with the problem of a node waiting to sync.

as i said. it would be a full node. this extra code to grab the utxo set from its connected peers first. and then syncs the blockchain second.
its not an electrum node with a few tweaks. its a full node with a couple tweaks

so seeing as it would be a full node, with all rules. and also as it syncs it is checking the data like all full nodes.
all that changes is that its actually able to spend funds at syncing from block 0 instead of waiting for block 420k+ to be properly usable.

its not like electrum or other lite wallets that rely on a central server. my idea is a proper full node but just things in a different order.. grabbing utxo data from nodes, probably safe to get utxo from all connections to have multiple opinions. and then build the blockchain after.

thus solving the long wait where users have to wait for the node to build its own utxo set

---to address morantis's new scenario about one source of data that multiple softwares can use.
you could set up a bitcoin Deamon on the data store. and then get other 'client' software to RPC call the data from it
but then its not really what i would call a full node anymore for the 'client' implementations

That is not true.  Even a linear line with slope zero is 'exponential' - the exponent being 0.  'exponential' is a bullshit term that is overused.  Basically, everything is 'exponential'.