Bitcoin scalability & financial & competition problems and solutions:
Link to youtube video discussing the above topics:
https://youtube.com/live/zT0fs8KtaG8List of concepts discussed/tags of video:
Bitcoin, Problems, Scalability, Financial, Costs, Competitor, Solutions, Distribution, Coins, Bittorrent, Merkle Hash Tree, Tree Numbering, Tree Node Number Translation, Redundancy, Risks, Storage, Root Hash, Intermediate Hash, Binary Tree, Growing Binary Tree, Tree Storage, Energy, Magnets, Glass, Lasers, Holy, 3D Glass, Seeking, Bandwidth, Network, Scanning, Number of Peers, Number of Nodes, Number of Blocks, Tree Blocks, Virtual Tree, Computational Tree, Partial Tree, Bitsets, Compressed Bitset.
17 FEBRUARY 2023 BY SKYBUCK FLYING.
(Sorry for Caps, don't mean to scream or anything, just makes it a bit easier to read on highly compressed video images)
Lately I have been thinking about the "financial costs" of the banking system.
Today I also more or less considered the "financial costs" of bitcoin.
And I more or less came to the conclusion that bitcoin might actually be more
expensive then the centralized banking system in a certain way, if true then I think
this high financial cost problem should be solved.
Bitcoin should be cheaper than the centralized banking system and not more
expensive.
I AM GOING TO DISCUSS THREE IMPORTANT TOPICS IN THIS VIDEO:
1. THE FINANCIAL COSTS OF BITCOIN AND HOW TO REDUCE IT.
2. THE SCALABILITY PROBLEM OF BITCOIN AND HOW TO REDUCE/SOLVE IT. THE SCALABILITY
PROBLEM ALSO AFFECTS/CAUSES TO FINANCIAL PROBLEM TO A CERTAIN DEGREE. IT ALSO
RELATES A LITTLE BIT TO THE MINING PROBLEM.
3. THE COMPETITOR PROBLEM.
4. THE MINING PROBLEM/COIN DISTRIBUTION PROBLEM.
THE MOTIVATION HERE:
IS DRIVING DOWN COSTS, BECAUSE COSTS ARE EXPLODING ACROSS EUROPE AT LEAST AND MAYBE
THE WORLD, POSSIBLY DRIVEN BY POLITICS, GREEN MOVEMENT, DRIVING UP PRICES
ARTIFICIALLY, ENERGY CRISIS, ENERGY PRICE HIKES AND ALSO SOME WAR AND TRADE BANS AND
KICKING COUNTRIES OUT OF THE FINANCIAL SYSTEM/SWIFT.
LIFE IS BECOMING EXPENSIVE, HOW TO REDUCE COSTS ?!
COMPETITION IS GOOD, BITCOIN COULD BECOME A COMPETITOR FOR THE FINANCIAL
BANKS/SYSTEM AND OFFER A CHEAPER ALTERNATIVE....
TO MAKE THE BITCOIN PROBLEMS PERFECTLY CLEAR IT HELPS TO EXAGARETTE THE PROBLEMS.
EUROPE CASE: IMAGINE IF 300.000.000 IN EUROPE START USING BITCOIN.
WORLD CASE: PROBLEMS WILL BE EVEN BIGGER IF 7.000.000.000 BITCOIN.
THE BITCOIN PROBLEMS:
1. THE FINANCIAL COSTS/PROBLEM AND WHAT CAUSES IT.
&
2. THE SCALABILITY PROBLEM.
BASICALLY EVERYBODY, EVERY FULL NODE HAS TO COPY/DOWNLOAD THE ENTIRE BLOCKCHAIN AND
THIS LEADS TO THE SITUATION WHERE EVERYBODY THAT WANTS TO RUN A FULL/SECURE NODE OF
HAVING TO BUY AT LEAST A VERY BIG EXPENSIVE HARDDISK.
300.000.000 X 1 HARDDISK X 500 EURO = 150.000.000.000 EUROS
NOW COMPARE THAT TO BANKS,CENTRALIZED BANKS
THE ONLY NEED A FRACTION OF THESE AMMOUNTS OF HARDDISKS
BANKS REQUIRE MUCH LESS HARDDISKS IF THEY USE A CENTRALIZED SYSTEM.
ALSO MAKING ALL THESE COPIES, REQUIRES A LOT OF BANDWIDTH AS WELL, ALSO A LOT OF
PROCESSING POWER, WHICH ALSO MEANS MORE ENERGY ETC.
TRANSACTION COSTS FOR BITCOIN ARE QUITE HIGH, BECAUSE STORAGE SPACE IS SO LIMITED,
IT IS BEING USED INEFFICIENTLY, BECAUSE OF ALL THESE MANY COPIES.
IF THE NUMBER OF COPIES WAS REDUCED AND INSTEAD THE HARDDISK SPACE MORE EFFICIENTLY
USED, THIS COULD ALLOW THE BLOCK-SIZE OF BITCOIN TO BECOME BIGGER/LARGER AND WOULD
ALLOW MORE TRANSACTIONS TO BE STORED IN THIS BLOCK, BASICALLY ALLOWING MORE
TRANSACTIONS PER 10 MINUTES, BASICALLY MORE TRANSACTIONS PER MINUTE BASICALLY AND
WOULD RELIEF SOME OF THE PRESSURE ON THE SYSTEM, BECAUSE BASICALLY USERS OF TODAYS
BITCOIN HAVE TO COMPETE WITH EACH OTHER TO GET THERE TRANSACTION THROUGH, BECAUSE
THE TRANSACTION STORAGE SPACE IS LIMITED AND ONLY THE TRANSACTIONS WHICH OFFER THE
HIGHEST TRANSACTION FEES ARE PROCESSED AND STORED IN THE BLOCKCHAIN...
IF EVERYBODY WOULD START USING BITCOIN IN IT'S CURRENT FORM IT WOULD DRIVE UP
TRANSACTION COSTS AND WOULD MAKE BITCOIN EVEN MORE EXPENSIVE.
THE MORE OR LESS CURRENT FINANCIAL BANKING SYSTEM COSTS ESTIMATION:
IT COSTS MONEY TO HAVE A BANKING ACCOUNT.
4 EURO PER MONTH FOR AN BANKING ACCOUNT.
EUROPE CASE:
300.000.000 PEOPLE x 12 MONTHS X 4 EURO = 14.400.000.000 EUROS PER YEAR.
EVERY BANK TRANSACTION MORE OR LESS COSTS:
15 EURO CENTS.
BUT SOME MIGHT BE MUCH MORE EXPENSIVE LIKE INTERNATIONAL TRANSACTIONS.
THIS COULD PROBABLY ADD ANOTHER FEW BILLION TO THIS COST NUMBER.
I DON'T KNOW THE EXACT COSTS HERE...
BUT THERE IS AN INCENTIVE FOR BANKS TO GET RID OF COMPETITORS INCLUDING CASH...
SO THAT IF EVERYTHING GOES VIA THEIR SYSTEMS, IT WILL DRIVE UP TRANSACTIONS AND THUS
THEY CAN ALSO MAKE A BIG PROFIT.
ROUGHLY SPEAKING AFTER 10 YEARS, BITCOIN AND BANKS ARE BREAK EVEN, EXCEPT BANKS
ACTUALLY SERVE A MUCH LARGE COMMUNITY.
RIGHT NOW I WOULD ESTIMATE BITCOIN AND BANKS ARE BREAK EVEN AFTER 10 YEARS, SO
CURRENTLY THERE IS NO REAL COST REDUCTION, WHICH SUCKS.
3. THE COMPETITOR PROBLEM.
BANKS HAVE WAKEN UP, CENTRALIZED BANKS HAVE WAKEN UP, AND THEY HAVE BECOME A BIT
NERVOUS ABOUT THIS BITCOIN TECHNOLOGY... THEY SEE IT AS A POTENTIAL THREAT TO THEIR
BUSSINESS/BUSSINESS MODEL AND THEY WORRY ABOUT BITCOIN IF IT WOULD EVOLVE INTO
SOMETHING MORE EFFICIENT... THEN BITCOIN COULD BECOME A SERIOUS COMPETITOR FOR
BANKS.
FOR NOW THE BANKS HAVE STARTED PLANNING, WHICH YOU MAY HAVE HEARD OF, A CENTRALIZED
DIGITAL CURRENCY/BANKING SYSTEM. BASICALLY SOME KIND OF DISTRIBUTED LEDGER SYSTEM
AMONG BANKS THEMSELFES... AND THEN LIGHT CLIENTS WOULD PROBABLY COMMUNICATE WITH
THESE HEAVY NODES RUNNING AT THE CENTRALIZED BANKS.
I REFER YOU TO GEORGE GAMMON'S YOUTUBE VIDEOS ABOUT THIS AND OTHERS THEN DISCUSS IT
IN MORE DETAIL HOW THAT COULD WORK AND HOW IT WOULD EFFECT THE FINANCIAL SYSTEM.
TO SUM UP GEORGE GAMMON'S HYPOTHESIS OF HOW THIS WOULD WORK:
1. COMMERCIAL BANKS WOULD KEEP SERVICING/MAKING LOANS TO COMMERCIAL
ENTITIES/ENTERPRISES/BUSSINESS.
2. THE CITIZEN ACCOUNTS WOULD TRANSFER/TRANSITION FROM THE COMMERCIAL BANKS TO A
CENTRALIZED BANK, THIS CENTRALIZED BANK WOULD THEN GET A LOT OF INSIGHT INTO THE
TRANSACTIONS OF ALL THE CITIZENS.
3. THE COLLECTION OF DATA ABOUT CITIZENS, FACE SCANNING, MOUTH SCANNING AND
PASSING/COLLECTING OF DATA OF BUSSINESS ANYWAY <- MIGHT BE INEVITEABLE.
HE SUGGESTS: BY ASSETS THAT PEOPLE WILL WANT IN THE FUTURE, TRADE IT AMONG EACH
OTHER.
MY PREDICTION/WORRY:
IF BITCOIN OR A NEW SYSTEM DOES NOT APPEAR, THEN BITCOIN WILL MORE OR LESS DISAPPEAR
TO THE BACKGROUND BECAUSE IT'S TOO INEFFICIENT, TO COSTLY... AND THE CENTRALIZED
BANKS AND COMMERCIAL BANKS, WILL BASICALLY WIN WITH THEIR SYSTEMS...
AND THEN THERE WON'T BE ANY COST REDUCTION FOR US ALL, WHILE I DO BELIEVE THAT
BITCOIN HAS THE POTENTIAL TO REDUCE THE COSTS OF THE BANKING WORLD.
THERE IS A RISK THAT THESE BANKS WOULD GET A MONOPOLY ON THE FINANCIAL TRANSACTIONS
AND START RISING COSTS, MAKING IT EVEN MORE EXPENSIVE IN THE FUTURE.
AND IT MIGHT ALSO MAKE THEM TO "POWERFULL"....
4. THE MINING PROBLEM/COIN DISTRIBUTION
50% ATTACKS, 33% ATTACKS.
SOME PEOPLE CONSIDER THIS PROBLEM SOLVED BY USING MINING POOLS.
I KINDA AGREE WITH THAT A LITTLE BIT, NOT ENTIRELY, BUT IT'S A NICE SOLUTION FOR
NOW.
BASICALLY THERE COULD BE 4 MINING POOLS, CLIENTS COULD BE DISTRIBUTED
"FAIRLY/EVENLY" AMONG THE MINING POOLS, SO THAT EACH MINING POOL HAS 25% OF THE
HASHING POWER.
THE SOLUTIONS TO THE SCALABILITY PROBLEM OF BITCOIN:
1. THE BLOCK STORAGE SYSTEM AND THE BLOCK DISTRIBUTION PROTOCOL:
BASICALLY THERE IS ALREADY A SOLUTION TO THIS PROBLEM AND IT IS CALLED:
BITTORRENT (BY BRAM COHEN, MIT UNIVERSITY)
BASICALLY IT DIVIDES DATA/FILES INTO BLOCKS AND DOWNLOADS THEM RANDOMLY AND
DISTRIBUTES THEM ACROSS MANY PEERS BY HEURISTICS AND A THIS FOR THAT PROTOCOL.
IT THEORETICALLY ALLOWS A FILE TO BE PARTIALLY STORED ON MANY COMPUTER DISKS.
SO BASICALLY EVERY PEER/EVERY COMPUTER DISK CAN ONLY STORE A FEW PIECES.
NOT ALL PIECES, NOT ALL BLOCKS HAVE TO BE STORED IN A SINGLE DISK...
IT IS POSSIBLY TO REQUEST CERTAIN BLOCKS ON A NEED-TO-KNOW BASIS.
1.1 THE ACCOUNTING FOR THESE BLOCKS CAN BE DONE WITH SOMETHING KNOW AS A BITSET, IT
IS POSSIBLE TO CODE A SCALABLE BITSET, BASICALLY A COMPRESSABLE BITSET, WHICH KEEPS
THIS ACCOUNTING IN MEMORY IN A COMPRESSED FORM AND CAN MOST LIKELY ALSO STORE AND/OR
TRANSMIT THIS IF NECESSARY IN A COMPRESSED FORM TO OTHER PEERS, SO THAT THIS DOES
NOT HAVE TO BECOME A TECHNICAL/LIMITING PROBLEM. SO THAT THE MEMORY SYSTEM DOES NOT
RUN OUT OF MEMORY. SINCE IT DOES NOT NEED TO BE DECOMPRESSED, THERE IS ALSO NO RISK
OF A DECOMPRESSION EXPLOSION, LIKE WITH WINZIP, EXTRACTING A 1 EXABYTE FILE WITH ALL
ZEROES OR SOMETHING CRAZY.
MY SUGGESTION HERE IS THAT EACH COMPUTER STORES 256 SEQUENTIAL BITCOIN BLOCKS, SO
THAT THESE CAN BE COMPRESSED IN A CERTAIN WAY, MULTI LEVEL WAY. IT'S KIND OF SECRET
TECHNOLOGY, DON'T HAVE TO USE IT.
WHAT IS NEEDED IS REAL-TIME QUEYRING OF THIS COMPRESSED BITSET.
1.2 BITCOIN ITSELF IS SOMEWHAT INEFFICIENT WITH THE VERIFIEING OF ALL THESE BLOCKS.
CURRENTLY THIS HAPPENS IN A SEQUENTIAL FASHION AS FAR AS I KNOW.
THE DATABASE/BLOCKCHAIN (LINKED CHAIN OR LINKED LIST)
GENESIS BLOCK 0 <- BLOCK 1 <- BLOCK 2 <- BLOCK 3 <- BLOCK 4
THERE IS ANOTHER WAY TO VERIFY THE INTEGRITY OF THE DATABASE:
MERKLE HASH TREE (BASICALLY A BINARY TREE, IT'S A COMPUTER CONCEPT/DATA STRUCTURE)
STATE:
ROOT HASH
/
BLOCK 0
STATE:
ROOT HASH
/ \
BLOCK 0 BLOCK 1
STATE:
ROOT HASH
/ \
INTER HASH INTER HASH
/ \ /
BLOCK 0 BLOCK 1 BLOCK 2
STATE 0
ROOT HASH
/ \
INTERMEDIATE HASH
/ \ /
INTERMEDIATE HASH INTER HASH HASH
/ \ / \ /
BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3 BLOCK 4
WHAT WOULD BE NEEDED FOR BITCOIN IS A DYNAMIC MERKLE TREE HASH WOULD BE NEEDED,
A TREE THAT CAN GROW. EVEN IF THIS TECHNOLOGY/CODE DOES NOT EXIST, THEN IT'S STILL
POSSIBLE TO USE EXISTING STATIC MERKLE HASH TREES AND MORE OR LESS RECONSTRUCT THE
TREE...
IT MIGHT NOT BE NECESSARY TO RE-CONSTRUCT, AT LEAST THAT IS THE HOPE.
STATE 1:
ROOT HASH
/ \
INTERMEDIATE HASH
/ \ \
INTERMEDIATE HASH INTER HASH INTER HASH
/ \ / \ / \
BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3 BLOCK 4 BLOCK 5
STATE 2:
ROOT HASH
/ \
INTERMEDIATE HASH
/ \ / \
INTERMEDIATE HASH INTER HASH INTER HASH HASH
/ \ / \ / \ /
BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3 BLOCK 4 BLOCK 5 BLOCK 6
STATE 3:
ROOT HASH
/ \
INTERMEDIATE HASH
/ \ / \
INTERMEDIATE HASH INTER HASH INTER HASH HASH HASH
/ \ / \ / \ / \
BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3 BLOCK 4 BLOCK 5 BLOCK 6 BLOCK 7
STATE 4:
ROOT HASH
/ \
IHASH IHASH
/ \ /
IHASH IHASH IHASH
/ \ / \ /
IHASH IHASH IHASH IHASH IHASH
/ \ / \ / \ / \ /
BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3 BLOCK 4 BLOCK 5 BLOCK 6 BLOCK 7 BLOCK 8
Apple's Steve Jobs would have called this: iCoin for your iPhone.
BASICALLY EACH PEER WOULD HAVE IT'S OWN TREE STATE.
THEORETICALLY IT WOULD BE POSSIBLE TO "TRANSLATE" THE NUMBER SCHEME ON THESE TREES.
SO BASICALLY FOR A PEER TO BE ABLE TO COMMUNICATE WITH ANOTHER PEER.
PEER A WITH PEER B.
PEER A MUST MORE OR LESS BE ABLE TO PEEK INTO THE MIND OF PEER B.
SO PEER A MUST KNOW: HOW MANY NODES ARE THERE IN THIS MERKLE HASH TREE.
BASICALLY PEER A ONLY NEEDS TO KNOW HOW MANY NODES THERE ARE IN THE TREE OF PEER B.
BASICALLY PEER A MUST KNOW HOW BIG IS THE TREE OF PEER B.
ILLUSTRATE A NUMBER SCHEME FOR THESE BINARY TREES
THIS IS USEFULL FOR AN EFFICIENT TREE COMMUNICATION PROTOCOL TO BE ABLE TO RETRIEVE
SOME OF THESE HASHES, NOT ALL HASHES HAVE TO BE ACQUIRED, I HAVE NOT YET EXPLAIN
THAT, TO VERIFY A NEW NODE, OR ANY LEAVE, NOT ALL HASHES ARE REQUIRED.
IT WOULD RESERVE 0 TO INDICATE UNKNOWN OR FAILURE OR SOMETHING.
LET'S START NUMBERING AT NUMBER 1.
STATE 4:
N1
ROOT HASH
/ \
IHASH N2 IHASH
/ \ /
IHASH N3 IHASH IHASH
/ \ / \ /
IHASH N4 IHASH IHASH IHASH IHASH
/ \ / \ / \ / \ /
BLOCK 0 N5 BLOCK 1 N6 BLOCK 2 N BLOCK 3 BLOCK 4 BLOCK 5 BLOCK 6 BLOCK 7 BLOCK 8
BITTORRENT.
USE A MERKLE HASH TREE TO STORE AND COMPUTE THE BLOCKS.
MAYBE LOOK INTO MY POSTING/CODE:
My posting on bitcoin forum:
"Distributed downloading of blocks using a merkle hash tree for the block chain."
Maybe I invented some number scheme which stays the same as the binary tree grows,
maybe not, it could probably be invented or re-invented, maybe it already exists.
Even if it does not exist. Nodes numbers of trees could be "translated".
So basically Peer A has it's own Tree Node Number scheme/numbering.
So basically Peer B has it's own Tree Node number scheme/numbering.
If Peer A can understand Peer B's numbering scheme or vice versa then PeerA and
PeerB should be able to "translate" the numbers from each other and be able to refer
to the same node that they want to discuss/communicate about it.
So the point is, even with different numbering scheme, this does not have to be an
issue. It can be computed mathematically, or even with a little bit of extra memory.
Maintaining a "growing" number scheme that stays the same no matter the tree state,
would just be an optimization.
WHERE TO STORE THE ROOT HASH
INSPIRATION FROM PASCALCOIN
BASICALLY STORE THE ROOT HASH IN EACH BLOCK AS IT CHANGES.
GENESIS BLOCK 0 BLOCK 1 BLOCK 2 BLOCK 3
IT'S OWN BLOCK HASH IT'S OWN BLOCK HASH IT'S OWN BLOCK HASH
ROOT HASH ROOT HASH ROOT HASH ROOT HASH
FOR EACH NEW BLOCK:
RE-COMPUTE THE ROOT HASH
AND
STORE THE ROOT HASH IN THE NEW BLOCK.
I11
I9 I10
I6 I7 I8
I1 I2 I3 I4 I5
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10
THE MEMORY REQUIREMENTS FOR A BINARY TREE COMPARED TO A LINKED LIST, DOUBLE.
WHICH REALLY ISN'T THAT BAD... AND THE ENTIRE TREE DOES NOT NEED TO BE STORED IN
MEMORY.
IT CAN ALSO BE STORED ON DISK.
THIS IS WHERE EXTRA TECHNOLOGY/SOURCE CODE IS NEEDED TO STORE THE TREE ON DISK.
BUT IT WOULD BE VERY USEFULL, IF THIS TREE CAN BE ACCESSED PARTIALLY FROM
DISK/PERMANENT/PERSISTENT STORAGE AND BE TRAVERSED/SEEKED WITHOUT LOADING THE ENTIRE
TREE INTO MEMORY.
I THINK IT WOULD BE PRETTY SMART TO USE A STORAGE SCHEME/TECHNOLOGY/METHOD/PATTERN
WHERE AT LEAST THE LEAVE NODES CAN BE RETRIEVED INDIVIDUALLY, ALSO INTERMEDIATE
NOTES, AND OFCOURSE ALSO THE ROOT NODE.
SO BASICALLY ANY POSITION/NODE IN THE TREE SHOULD BE RETRIEVALE FROM THIS STORAGE
TECHNOLOGY EFFICIENTLY, WITHOUT REQUIRING TO LOAD THE ENTIRE TREE INTO MEMORY.
IT'S PROBABLY POSSIBLE TO DO THIS, TO DO THIS, THE EASIEST WAY WOULD BE TO MAKE SURE
THAT EACH NODE HAS THE EXACT SAME SIZE AND HAS A FIXED SIZES.
THIS SHOULD MAKE IT EASY TO COMPUTE AN LINEAR/SEQUALTIAL OFFSET FROM THE START OF
THE FILE TOWARDS SOME NODE POSITION IN THE TREE.
SO THIS TREE BASICALLY BECOMES VIRTUAL OR ANY TERM, A COMPUTATIONAL TREE, WHERE THE
NUMBER SCHEME IS USED TO FINALLY COMPUTE THE NODE OFFSET IN THE FILE.
AND THUS A DIRECT SEEK INTO THIS POSITION IN THE FILE CAN BE DONE AND THE NODE READ.
AT THE END OF THE FILE NEW NODES SHOULD BE ABLE TO BE ADDED.
ANOTHER IDEA COULD BE TO SPLIT THE TREE INTO MULTIPLE FILES. BUT THIS WOULD PUT
EXTRA STRAIN ON THE FILE SYSTEM, THOUGH MAYBE THIS HAS SOME KIND OF BENEFITS...
ONE SIMPLE BENEFIT COULD BE TO RE-USE THE "SEEKING" CAPABILITY OF THE FILE SYSTEM...
BASICALLY THIS WOULD ALLOW THE PROGRAMMER TO COMPUTE A FILENAME, MAYBE EVEN A FOLDER
NAME, THOUGH I DON'T RECOMMEND USING SUB FOLDERS TO STORE THE TREE, BASICALLY
WINDOWS EXPLORER HAS LIMITATIONS AND HAS DEPTH LIMITATIONS.
BUT AT LEAST THE FILENAMES CAN BECOME QUITE BIG... HOWEVER... FILENAMES WOULD
ULTIMATELY RUN INTO THEIR OWN LIMITATIONS, I AM NOT SURE WHAT CURRENT LIMITATION
IS... NTFS PROBABLY HAS SOMETHING LIKE MAYBE 2 GB LIMITATION OR MAYBE 64 GB
LIMITATION.
SO A DOWN SIDE OF THIS IDEA, IS EXTRA STORAGE SPACE NEEDED FOR THE FILENAMES...
BUT AN ADVENTAGE WOULD BE NO OFFSET COMPUTATIONS FOR VARIABLE NODE SIZES THIS COULD
BE AN ADVANTAGE... AND THEN YOU SIMPLY LET THE FILE SYSTEM SEEK THE FILE AND OPEN IT
AND LOAD IT.
ANOTHER IDEA COULD BE OFCOURSE TO USE "DATABASE" TECHNOLOGY TO STORE THESE NODES AND
TREE HASH NODES AND SO FORTH.
AND THEN BITCOIN WILL BE AFFECTED/LIMITED AND/OR ENHANCED BY THE
PROPERTIES/LIMITATIONS OR BENEFITS OF SUCH A DATABASE TECHNOLOGY.
IT DOES ADD SOME COMPLEXITY TO THE SYSTEM.
THE IDEA BEHIND THIS DISCUSSION, IS HOW TO IMPLEMENT IT AS FAST AND LAZY AS
POSSIBLE, IF YOU TOO LAZY TO CODE IT DIRECTLY.
BY COMBINING BITCOIN + BITTORRENT + MERKLE HASH TREES + MERKLE HASH TREE
COMMUNICATION PROTOCOL/TREE NUMBERING SCHEME + TREE NUMBER SCHEME TRANSLATION OR A
STEADY/GROWING TREE NUMBERING SCHEME + MERKLE HASH TREE STORAGE/RETRIEVAL TECHNOLOGY
+ NETWORK SCANNING NUMBER OF PEERS, NUMBER OF TREE BLOCKS + STORING ROOT HASH PER
TREE LEAVE BLOCK + EACH LEAVE BLOCK HAS IT'S OWN BLOCK HASH.
IT BECOMES POSSIBLE TO MAKE BITCOIN EFFICIENT AND SCALABLE.
HOW TO ACTUALLY USE BITTORRENT TO DISTRIBUTE THE BITCOIN BLOCKS AMONG PEERS.
STEP 1.
EACH PEER WOULD NEED TO KNOW HOW MANY PEERS THERE ARE IN THE ENTIRE NETWORK.
NETWORK PEER SCANNING PROTOCOL. THE NETWORK MUST MAINTAIN SOME KIND OF IDEA/NUMBER
OF HOW MANY PEERS THERE ARE IN TOTAL.
STEP 2.
EACH PEER WOULD NEED TO KNOW ROUGHLY HOW MANY BLOCKS THERE ARE IN THE BLOCK TREE.
STEP 3 CALCULATE SOME KIND OF DISTRIBUTION RATIO
NUMBER OF BLOCKS IN TREE / NUMBER OF PEERS =
1.000.000 / 10.000 = So each peer has to store at least a mimimum of 100 blocks.
However there would be no redundancy yet, which means if a peer goes offline 100
blocks would be missing.
So there should be some kind of "redundancy factor".
For example each tree block is not stored just 1 time, but for example at least 3
times, for tripple redundancy like data centers.
But it could also be 10x because, 100 blocks is not that much.
This could also be left up to the user, how much redundancy the user wants to
contribute to the network in total, though, it does become maybe a little bit risky
if this particular user goes offline... not sure exactly... how these kinds of
decisions would affect the network...
But at least there is some redundancy... which is also what was build into
bittorrent.
Furthermore bittorrent basically allows allows "seekablelity".
Anyway block may be requested/downloaded at any time.
The blocks do not need to be downloaded in sequence. It can be downloaded in any
order, at any time, not all blocks need to be downloaded, only the once that are
necessary for for example verification purposes.
Or to check if the bitcoin address has balance/spendable outputs, etc.
So benefits of this idea are plenty:
1. Clients can much faster join the bitcoin network and don't need to download a
huge blockchain.
2. Clients can operate much more efficiently storage wise, and don't need to buy
extra/new/bigger harddisks.
3. There is an incentive for clients to join and operate the network at all times,
because as the number of clients goes UP, the number of blocks to store actually
goes DOWN, most likely, to some degree. Unless all the clients start spamming
transactions like crazy, but must likely clients won't do this, because there should
always be a small transaction fee to prevent them from spamming transactions.
Plus at least citizens don't really do that many transactions per day or per week.
Some companies might.... but that is kinda the idea to bring them along with it...
and they can now benefit from a cheaper financial transaction system that is carried
basically by the entire world, anybody that has a computer.
Also other companies like Google, Microsoft, Facebook, Apple, might also be
interested in providing some storage space to help with the increase usage of the
bitcoin system as it becomes more populair.
4. Most likely less bandwidth used, because only the necessary blocks and hashes
need to be downloaded and not the entire blockchain.
So basically while a tree is a less efficient storage structure at first glance,
looking at the total number of nodes used, a tree does allow and does have certain
properties that more or less makes it more efficient for very large systems...
because part of the tree can be ignored.
Basically like windows explorer where sub folders can be collapsed, or other GUI
trees.
You spend a little bit more on the tree size, but also because every computer only
has to store parts of the tree it can be stored more efficiently.
The tree can also be virtual/computed by math.
And math requires some processing power, it's basically pretty cheap, it just
requires some electricity, however with todays rising energy cost... hmmmmmmmmm....
if the energy costs keep rising, someday it might be cheaper to just store the tree
on disk, instead of re-compute it... this is just part of life and how the world
changes... hard to predict... but at least there are transition options, in case the
world changes.
Question: Will energy/electricity become cheaper or more expensive ?
It's hard to say:
There is solar energy, wind energy, nuclear energy, maybe fusion energy in the
future.
But there is also increased demand for energy:
Electric cars, Lots of computer chips, other computer equipment, other electronics.
Basically the magnetics on a harddisk are kind of free.... they might have to be
refreshed/read/written from time to time. (Head movement cost energy).
Solid State Disks ? Don't know how costly these are in terms of watts. I would
expect that all those components take energy ?! Not sure...
Futuristic technology like holo lens ? Some kind of technology from Microsoft,
written bits of data into glass and reading it out with lasers maybe.
Some kind of 3 dimensional glass laser storage technology. Huge capacity.
The laser will require energy to read/write, but the glass is probably free.
DISTRIBUTING PEERS AMONG MINING POOLS.
BECAUSE MINING POOLS ARE SO FAR THE BEST SOLUTION TO TRY AND DISTRIBUTE THE COINS
BEING MINED BY PROOF OF WORK MORE FAIRLY +
DISTRIBUTION OF TRANSACTION FEE COINS COULD AND SHOUKLD ALSO BE DONE VIA MINING
POOLS.
SO THAT CLIENTS CAN GET A FAIR SHARE OF THAT.
HOWEVER TO PREVENT THE MINING POOL OPERATOR/BOSS FROM PERFORMING A 51% OR 34%
ATTACK, MAYBE THERE WAS EVEN A 25% ATTACK POSSIBILITY, IT WOULD BE NECESSARY TO MAKE
SURE THAT THE MINING POOLS HAVE EQUAL HASH RATE/EQUAL POWER TO COMPUTE NEW BLOCKS.
MY ADVISE WOULD BE TO HAVE AT LEAST 4 MINING POOLS, BUT 5 WOULD PROBABLY BE A LITTLE
BETTER. THEN AGAIN AN UNEVEN NUMBER NOT SURE... 6 IS A BIT DEVILSH... IF TOO MANY
POOLS THEN THE TEMPTATION EXISTS TO MERGE THEM INTO BIGGER/STRONGER POOLS.
SO THE SOMEWHAT RISK SWEET SPOT WOULD PROBABLY BE 4 POOLS, TO AT LEAST BE ABLE TO
TWART THE 33% ATTACK POSSIBILITY, I AM NOT SURE IF A 25% ATTACK POSSIBILITY.
EACH MINING POOL SHOULD HAVE 25% OF THE TOTAL HASHING POWER.
This does not discuss the possibility of "dark/hidden mining" it does not discuss
the possibility of "partial block mining".
This may have to be looked at into the future. Not going to discuss this now...
*** MORE ON FAIR COIN DISTRIBUTION AND MINING POOLS ***
IF HASHING POWER OF EACH MINING POOL IS BETWEEN 24.5% AND 25.5% THEN JOIN RANDOMLY.
IF HASHING POWER OF THE JOINED MINING POOL EXCEEDS 33% LEAVE THE MINING POOL AND
JOIN ANOTHER MINING POOL IF AVAILABLE. (MAYBE NOT SUCH A GOOD IDEA IF A MINING POOL
GOES DOWN, WOULD LEAD TO A LOT OF EXTRA NETWORK TRAFFIC, BUT WOULD AT LEAST ENSURE
THAT CLIENTS REMAIN OPERATIONAL IN THE SENSE OF MINING, SO THAT THEY CAN CONTINUE TO
GET THEIR FAIR SHARE OF COINS), ALSO JOIN ANOTHER MINING POOL IF CURRENT MINING POOL
IS NON-FUNCTIONAL, IF AN ALTERNATIVE DOES EXIST AND CURRENT MINING POOL ABOVE 33%
THEN LEAVE EXISTING MINING POOL AND JOIN NEW MINING POOL. I DO SEE AN ATTACK
OPPERTUNITY HERE... WHERE CLIENTS COULD BE FOOLED AND JOIN BULLSHIT/FAKE MINING
POOLS... SO MY SUGGESTION WOULD BE TO HARD CODE AND/OR BITCOIN SOFTWARE ITSELF
SHOULD BE AUTHORITIVE IN THIS SENSE AND MAYBE THERE CAN BE SOME SPECIAL
INFRASTRUCTURE THAT VERIFIES IF MINING POOLS/OPERATORS ARE REAL/TO BE TRUSTED OR
FAKE... MAYBE REQUIRE SOME KIND OF REGISTERATION IN A REGISTRY, OR REQUIRE SOME
FEES/FUNDINGS TO ALLOW OPERATION OF A MINING POOL... MAYBE COULD EVEN PROVIDE A
LITTLE BIT OF INCOMING FOR THE BITCOIN DEVELOPERS THEMSELFES AND/OR FOUNDATION SO
THAT THESE MINING POOL REGISTRATION COSTS GO INTO THE BITCOIN FOUNDATION AS A KIND
OF FUNDING FOR THE BITCOIN DEVELOPERS, WHICH COULD BE USED FOR SOME PURPOSES.
IN RETURN THE BITCOIN SOFTWARE AUTHENTICATIONS THESE MINING POOL OPERATORS AS VALID,
THOUGH MAYBE SOME ADDITIONAL TECHNOLOGY CHECKS SHOULD BE DONE, OTHERWISE SOMEBODY
WITH SOME MONEY, COULD STILL BUY/FAKE IT'S WAY INTO THE MINING POOL OPERATER
REGISTRY, WHOEVER RUNS THIS REGISTRY COULD RUN SOME KIND OF VERIFIEING SOFTWARE TO
ESTIMATE IF IT'S REAL OR FAKE.
SO BASICALLY MINING POOL CLIENT (BASICALLY THE BITCOIN PEER) CAN LEAVE THE CURRENTLY
JOINED MINING POOL, IF THE CURRENTLY JOINED MINING POOL EXCEEDS 33% HASH RATE OR
SOME OTHER HASH RATE THAT MUST NOT BE EXCEEDED (DEPENDING ON MINIMUM AMMOUNT OF
MINING POOLS THAT SHOULD EXIST) AND THEN REJOIN THE MINING POOL WITH EITHER THE
LOWEST AMMOUNT OF HASH RATE (THOUGH IT COULD BE A TRICK), OR MAYBE COMPUTE A LIST OF
OTHER MINING POOLS THAT COULD BE JOINED, IN CASE THEY ALL HAVE A LOWER HASH RATE
THAN THE TARGET AVERAGE OF 24.5%, AND THEN JOIN ONE OF THEM RANDOMLY.
IT'S PROBABLY BETTER TO STAY WITH THE IDEA OF ONLY 4 MINING POOLS, SO THAT THE
CHANCE OF ACTUALLY OBTAINING BITCOINS IS ACTUALLY MAXIMIZED UNDER THESE CONDITIONS.
SO BASICALLY THE TOP 4 MINING POOL HASH RATES SHOULD BE EXAMINED.
AND THE LOWER MINING POOLS SHOULD DISSOLVE AND REJOIN THE TOP 4.
SO THAT ULTIMATELY THERE WILL BE 4 MINING POOLS WHICH EACH AROUND 25% HASHING POWER.
THIS CREATES THE MOST FAIR COIN DISTRIBUTION MODEL/SITUATION, WHERE PEERS DON'T HAVE
TO WORRY, THAT THEY JOINED A WEAK MINING POOL, WHERE THEIR CHANCE OF OBTAINING COINS
IS REDUCED, TO SIGNIFICANTLY REDUCED...
SO THIS 4 IDEA MINING POOL IDEA, GIVES THEM THE BEST CHANCE.
1. BITCOIN STORAGE PROBLEM: SOLVED BY BITTORRENT, REDUNDANCY, NETWORKS SCANNING AND
STORING ONLY A FEW BLOCKS PER COMPUTER.
2. BITCOIN BANDWIDTH PROBLEM: SOLVED BY NUMBER 1, PLUS MERKLE HASH TREE, PLUS MERKLE
HASH TREE PROTOCOL, NUMBERING SCHEME, STORING BLOCKS IN A TREE, INSTEAD OF A CHAIN.
3. BITCOIN COIN DISTRIBUTION PROBLEM: SOLVED BY CLIENT/BITCOIN SOFTWARE REQUIREMENT
TO JOIN ONE OUT OF FOUR MINING POOLS.
4. COMBINING ALL OF THESE SOLUTIONS SHOULD SOLVE THE COMPETITOR PROBLEM OF
CENTRALIZED DIGITAL BANKING SYSTEM, AND SHOULD OFFER VERY THOUGH COMPETITION TOWARDS
THIS CENTRALIZED DIGITAL BANKING SYSTEM. BASICALLY THIS SHOULD MAKE BITCOIN OR ANY
OTHER COIN SYSTEM THAT IMPLEMENTS THESE IDEAS FROM BEING MUCH MORE CHEAP TO RUN.
THE COSTS OF RUNNING ARE TRUELY DISTRIBUTED ACROSS ALL PEERS/ACROSS THE WORLD,
EVERYBODY DOES A LITTLE BIT, JUST ENOUGH TO KEEP THE SYSTEM RUNNING SMOOTH AND
REDUNDANT, BUT WITHOUT GOING COMPLETELY OVERKILL, WHICH IS WHAT THE CURRENT BITCOIN
SYSTEM IS, TOTAL REDUNDANCY OVERKILL.
Note: Maybe look further into "distributing" the tree nodes among peers.
I do believe that this is an unsolved problem, an issue not looked at yet.
The intermediate hash nodes of the tree, should be stored somewhere.
Some data, some blocks are needed to compute theses... and these hashes should be
stored somewhere so that they don't need to be recomputed.
Something new will have to be invented to distributed a binary tree, partially among
computers.
Maybe such a technology already exists.
Maybe look into my own posting to see if a stable growing number scheme is possible:
"Distributed downloading of blocks using a merkle hash tree for the block chain."
But this is not enough, but it is a start.
Even without a number scheme, translation could be used...
And I am thinking of simple numbering all the tree nodes "virtually" and then
pretending that these are all stored in a "bittorrent" like file.
So most likely bittorrent can also be used for the tree nodes/intermediate nodes
distribution.
Basically bittorrent would already be used to distribute the end leaves of the
merkle hash tree.
So it shouldn't be a too big deal to also use this same code infrastructure to also
distribute the intermediate hashes....
SO EACH TREE NODE SHOULD BASICALLY HAVE A TYPE TO INDICATE IF IT'S:
1. A ROOT HASH (MAYBE THIS TYPE NOT REQUIRED, BUT MIGHT BE HANDY OR NOT HANDY)
2. AN INTERMEDIATE HASH
3. A ENDLEAVE/DATA BLOCK HASH.
USE BITTORRENT PROTOCOL TO DISTRIBUTE PARTIALLY THESE NODES.
IF THE NODE IS A ROOT NODE OR INTERMEDIATE NODE THEN ONLY A HASH HAS TO BE STORED.
IF THE NODE IS A ENDLEAVE NODE THEN ALSO STORE THE DATA FOR THE TRANSACTIONS/DATA
BLOCKS PLUS IT'S HASH, PLUS ALSO THE ROOT HASH INSIDE THIS DATA BLOCK.
SO A LOT OF WORK REQUIRED TO RE-PURPOSE THE BITTORRENT PROTOCOL PLUS SOME
EXTRA/ADDITIONAL CODE FOR MERKLE TREE HASH
FINAL CONCLUSION:
IF THE BITCOIN DEVELOPERS BECOME LAZY AND DON'T INNOVATE, OR OTHER CRYPTOCOIN
PROJECTS, IF THEY THINK THEY ARE GOING TO BEAT THE BIG CENTRALIZED/COMMERCIAL BANKS
THEN IT MIGHT BE TIME FOR THEM TO WAKE UP, RALLY THE TROOPS, FIND NEW ENERGY,
BECAUSE A BATTLE FOR THE FUTURE OF THE FINANCIAL SYSTEMS IS ABOUT TO BE UNLEASHED BY
THE BANKS.
THE BANKS ARE PLANNING, TRYING AND ATTEMPTING TO IMPLEMENT SOME KIND OF CENTRALIZED
DIGITAL CURRENCY SYSTEM.
WITHOUT FURTHER IMPROVEMENTS TO BITCOIN AND OTHER CRYPTOCOIN PROJECTS THEY WILL
PROBABLY EVENTUALLY END UP WITH A MORE EFFICIENT FINANCIAL SYSTEM, THAT WILL BE
CHEAPER TO RUN AND THEREFORE ULTIMATELY IT WILL BEAT THE LIVING SHIT OUT OF OTHER
EXISTING CRYPTOCURRENCIES.... AND THEY MAY BE ABLE TO OFFER MUCH CHEAPER
TRANSACTIONS WORLD WIDE... THAN ANY OTHER CRYPTOCURRENCIES...
BASICALLY DESTROYING THE OTHER CRYPTOCURRENCIES COST-WISE.
THE ONLY REMAINING PEOPLE RUNNING THE OTHER CRYPTOCURRENCIES WOULD BE THE SO-CALLED
"FREEDOM FIGHTERS" THAT DON'T CARE ABOUT THE COSTS OF TRANSACTIONS, BUT THEN THEY
WOULD KINDA LOOSE OUT IN THE MONEY... AND START TO BECOME POOR.. AS EVERY
TRANSACTION THEY DO IS JUST VERY COSTLY....
IF YOU WANT GLOBAL ADOPTION OF SOME CRYPTOCURRENCY, IT SHOULD BE CHEAPER THAN THE
BANKS... AND THE WAY TO DO THAT IS TO MAKE IT CHEAP TO SCALE SUCH A CRYPTOCURRENCY.
IT IS A VERY HEAVY/KIND OF EMOTIONAL BURDEN ON THESE KINDS OF DEVELOPERS TO
TRANSITION THE ENTIRE WORLD INTO SUCH A CHEAPER FINANCIAL SYSTEM.
THERE ARE UNKNOWNS, THERE ARE RISKS, THERE ARE LEGAL ISSUES, THERE ARE WHAT IF COINS
ARE STOLEN ISSUES... BUT THOSE UNKNOWNS AND RISKS REMAINS TO BE SEEN....
IT'S ABOUT RISK TAKING... DO YOU WANT TO TAKE THESE RISKS ? THAT IS UP TO YOU TO
DECIDE AS A DEVELOPER, IF YOU WANT TO GET INVOLVED WITH RISKY BUSSINESS AND ALSO
CAUSE RISKS FOR OTHER PEOPLE USING THIS KIND OF SYSTEM...
RISKS OF CRYPTOCURRENCY COIN SYSTEMS:
1. HARDWARE VUNERABILITIES IN COMPUTER CHIPS/PROCESSORS/RAM/ELECTRONICS.
2. SOFTWARE VUNERABILITIES IN OPERATING SYSTEM, BIOS, CLIENT SOFTWARE, ADDITIONAL
SOFTWARE.
3. NETWORK ATTACKS, DENIAL OF SERVICE.
4. POLITICS/RULE RISKS, MAYBE BANS OF CERTAIN ADDRESSES IN SOFTWARE.
5. LEGAL RISKS, MAYBE POLITICIANS/LAW MAKERS/LEGAL SOFTWARE REQUIRING CERTAIN
PATCHES/UPDATES/RULES TO THE SOFTWARE, FOR EXAMPLE BAN CERTAIN ADDRESSES, MAYBE
BECAUSE OF TERROR THREATS, "RETURNING LOST COINS", THIS PUTS THE WHOLE IDEA OF
CRYPTOCURRENCY ON SLIPPERY ICE...
6. THEFT OF COIN, INFILTRATING SOMEBODY'S COMPUTER SYSTEM, HACKERS, HI-JACK, SPYING,
TROJANS.
7. HARDWARE FAILURES.
8. SOFTWARE FAILURES/BUGS.
9. ENERGY/ELECTRICITY DEPENDENT.
10. ELECTRONICS DEPENDENT (CHINA, TAIWAN, EU, USA)
11. SOFTWARE/PROGRAMMER DEPENDENT, COMPILER DEPENDENT, PROGRAMMING LANGUAGE
DEPENDENT.
12. TYPO RISKS... GUI MISTAKES RISKS...
Bye for now,
Skybuck.
P.S.: The part I loved the most was: iCoin =D
