Author

Topic: Bitcoin scalability & financial & competition problems and solutions (Read 94 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
With "the accounting" I ment keeping track of request,downloading,uploading bittorrent blocks/pieces. The computer must know who has what blocks, that's "pieces accounting".

I see. But i expect such accounting list/book would be big since there are currently 777487 blocks.

Your feedback was kinda interested, it kind of made me realise that "verification of all blocks" does not necessarily need to occur by everybody.

As long as the root hash is generally accepted by many computers, then it can be assumed that some parts of the tree are verified by others, who may be involved in the transactions in those blocks.

So theoretically it would only be necessary for computers involved with the latest bitcoin transactions in the latest block to verify those... if enough verifications then the other computers in the network can assume that the verification was done and was accepted/successfull.

It's a somewhat interesting idea.

But on practice, this idea (only verify some blocks or verify block which contain one's transaction) is in very awkward position.
1. People who run full node generally want to perform full verification or have all data (e.g. to run block explorer).
2. Average user would prefer SPV wallet which only download very few data (block headers, transactions and necessary merkle root for verification) rather than download and verify all blocks which contain their transaction.

If you have understanding why a merkle hash tree can be used to verify leave nodes, then you will have to read up how a merkle hash tree works, it's quite simple really.

I will try and explain the core concept with a very small tree of only 3 nodes.

1 root hash node

2 leave nodes:

To compute the root hash node (or intermediate node) a new/root/intermediate hash is computed as follows:

Intermediate Hash = Hash( Leave node 1 hash + Leave node 2 hash);

So basically the leave node 1 and leave node 2 hashes are "glued" to each other and a hash calculated over it and stored.

If any bit changes in the leave nodes it will be detected...

This process will be repeated for any higher nodes in the tree till the "root".

If any bit gets corrupted anywhere in the tree, the root node hash will have changed.

So to detect where the change happened, one goes down the tree, left and right and then checks if left changed or right changed or both...

And thus one "goes down" the tree to find where a bit flip occured...

I do see one problem though:

If the computers/users involved with the transactions are not online then they won't verify the transactions/block, so then somebody else would have to verify it...

Thanks for the explanation, although i already basic idea about how merkle root works. And FYI i just remember some parts of idea is similar with concept of sharding which used on few database and cryptocurrency (such as Ethereum) where problem you mentioned is also exist on different application.
full member
Activity: 384
Merit: 110
With "the accounting" I ment keeping track of request,downloading,uploading bittorrent blocks/pieces. The computer must know who has what blocks, that's "pieces accounting".

Your feedback was kinda interested, it kind of made me realise that "verification of all blocks" does not necessarily need to occur by everybody.

As long as the root hash is generally accepted by many computers, then it can be assumed that some parts of the tree are verified by others, who may be involved in the transactions in those blocks.

So theoretically it would only be necessary for computers involved with the latest bitcoin transactions in the latest block to verify those... if enough verifications then the other computers in the network can assume that the verification was done and was accepted/successfull.

It's a somewhat interesting idea.

If you have understanding why a merkle hash tree can be used to verify leave nodes, then you will have to read up how a merkle hash tree works, it's quite simple really.

I will try and explain the core concept with a very small tree of only 3 nodes.

1 root hash node

2 leave nodes:

To compute the root hash node (or intermediate node) a new/root/intermediate hash is computed as follows:

Intermediate Hash = Hash( Leave node 1 hash + Leave node 2 hash);

So basically the leave node 1 and leave node 2 hashes are "glued" to each other and a hash calculated over it and stored.

If any bit changes in the leave nodes it will be detected...

This process will be repeated for any higher nodes in the tree till the "root".

If any bit gets corrupted anywhere in the tree, the root node hash will have changed.

So to detect where the change happened, one goes down the tree, left and right and then checks if left changed or right changed or both...

And thus one "goes down" the tree to find where a bit flip occured...

I do see one problem though:

If the computers/users involved with the transactions are not online then they won't verify the transactions/block, so then somebody else would have to verify it...

full member
Activity: 384
Merit: 110
Follow up video:

https://youtube.com/live/dHdQmA-qQKE

BlockTree double spend problem (PascalCoin can probably solve it)

17 february 2023 by Skybuck Flying.

I thought a little bit about the previous video:

https://youtube.com/live/zT0fs8KtaG8

Bitcoin scalability & financial & competition problems and solutions

I see a "little problem" with this BlockTree idea.

It is (for starters) the double spending problem.

(I don't know much about how transactions are stored in the blocks, I don't really care, maybe I should or maybe

I should think of something else).

PascalCoin uses accounts, which might already solve, probably does solve the problem I am about to describe, and

it uses a concept called "SafeBox". It might be required to make bitcoin scalable... but then it looses a bit of

privacy.


Let's suppose there is a bitcoin address containing 50 coins.

Let's suppose the transaction that more or less mined these coins is in


                Block 3

             Mined 50 coins bitcoin address A




                        Double Spend attempt        Double Spend attempt
                                                           in single block             in multiple blocks.

                                                             Block 5                   Block 20

                                                      Try Spend 50 coins towards       Try Spend 50 coins
                                                       bitcoin address B               towards bitcoin address D

                                                      Try Spend 50 coins towards
                                                       bitcoin address C
               


The problem is the client needs more information, multiple blocks to be able to determine if bitcoins were

already spent... it must check for double spend attempts.


One simple idea would be to add links from Block 3 to the other Blocks so that the expenditure can be

checked/traced.

Ofcourse you cannot change block 3, because it's protected by hashes and such, you don't want to alter history.

But bitcoin does want to track how coins/addresses are spend.

Maybe some kind of link structure.


PascalCoin seems to be using "account blocks"...

It computes a hash across all account blocks, basically the safebox hash.

and the safebox hash is also stored in the blocks mined...

and then before trying to spend coins it will probably check the accounts and also mempool to detect any

attempts to spend coins that are simply not there or double spends.


So then the block tree would look more like:


      Block 3                           Block 5

      wants to spend 50 coins         
      from account number A to account number B


Theoretically PascalCoin can compute exactly in which account block the account is in. (But only if the number

of accounts remains constant per block, or it would have to use a more complex code/formula in case it changes

from a certain block number).

And then it can immediately retrieved both account blocks which are necessary.

The account block containing account number A
the account block containing account number B

So the account blocks can also be stored as an AccountBlockTree and BitTorrent could be used for this as well or

a similiar protocol.

To distribute these account blocks with a certain redundancy through the network, without actually storing all

of them on a single computer.

So there is some benefit to this BlockTree idea, at least for PascalCoin.


full member
Activity: 384
Merit: 110
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
Jump to: