Bitcoin scalability & financial & competition problems and solutions:

[Skybuck Flying]

Bitcoin scalability & financial & competition problems and solutions:

Link to youtube video discussing the above topics:

https://youtube.com/live/zT0fs8KtaG8

List 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