Bitcoin Forum
April 20, 2024, 02:37:15 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin Technical Introduction for programmers  (Read 1356 times)
jerfelix (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250


View Profile
February 07, 2013, 11:24:37 AM
Last edit: February 07, 2013, 11:52:47 AM by jerfelix
 #1

I wrote this up, trying to give an introduction to Bitcoin to technical people (specifically some programmers I know).   I figured I'd post it here, in case someone else can use it.

It's long, sorry.  Feedback welcome.



For the non-technical person, it’s best to think of Bitcoins as currency like the Euro or like Gold.  It has properties like both.  First, the price fluctuates.  Second, you can spend it, save it, convert back and forth between dollars.



For the technical understanding, you have to know a little about digital signatures and hashing.  You just need to know that there are “1 way” math functions where it’s easy to go one way, and hard (impossible, practically speaking) to go the other way.  Like factoring large numbers.  It’s easy to create a large multiple of two really large primes, and it’s hard to factor the result.   Public key encryption and digital signatures use this feature of math – that 2 numbers, the “key pair” have a special mathematical relationship to each other.

I think Bitcoin is a weird name.  Because it’s really not a coin.  I think looking at a paper wallet helps to understand.   If you go to www.bitaddress.org, you’ll see that you get a public key and a private key.   Those two numbers have a mathematical property such that it’s easy to have derived the public key from the private key, but hard to go the other way.  In addition, you can prove that you are in possession of the private key, without ever divulging it.



For a banking analogy, the public key is like your checking account number.  You can tell people your checking account number (like you tell your company, for direct deposit).  You can accept payment to your checking account, by giving people the number.  There's not a lot of risk in divulging your checking account number, although I wouldn’t post my checking account number on the internet, because spending (or raiding your account) in the traditional banking sense isn’t as secure as in the Bitcoin world.  But your account number is something that’s OK to share, for people to deposit to.  This is like your “Bitcoin Address” or public key.

The private key is like your Debit Card, Pin, CVV/CVC code and Signature all wrapped in one.  In traditional banking, if you want to spend your money, you usually have to give this information over to the person you are spending it with.  And by doing so, you are allowing them to raid your account, but you are trusting them that they will only take the amount that you authorize.  

With Bitcoin, if you reveal your private key, then the person also can take all your money.  But the beauty of the math is that you don’t need to reveal it to prove that you have it.  So in this sense, Bitcoin is far more secure than traditional banking.  If I want to spend money in account “A”, all I need to do is prove that I am authorized (i.e. that I have the private key in my possession), and I can spend money in account “A”.



More banking analogy:   There are no coins in Bitcoin.  There are only ledger entries.  Picture a giant paper ledger at a central bank.  If I have money in account  “A” and I send it over to you, at account “B”, then there’s a one-line transaction in this paper ledger that says “debit column ‘A’ and credit column ‘B’”.  Further, you can look back in the ledger, examining column “A” and see that account ‘A’ has a positive balance by looking at the transaction that credited “A” originally.

A major technical breakthrough of Bitcoin is that they figured out how to implement all this, without having to trust a central bank to maintain the ledger.  Instead, the ledger is held in a peer-to-peer network.  Everyone can see the entire history of all transactions (if you want to), and follow any money from one account number to another (you don’t know who owns the account numbers, which is why they say it’s pseudonymous).  You can literally “follow the money”.



So when you spend money, you digitally “sign it over” to the other party.  Your digital signature proves that you have the right to spend it, and creates one transaction in the ledger that “moves” the money from your account to someone else’s.  And since people can own multiple accounts (“Bitcoin Addresses”), one transaction can move money from several accounts and to several accounts (including moving money internally from one account of yours to another).   A very frequent transaction that you’ll see is… say I want to give you 3.50 Bitcoins, and I have a Bitcoin Address with 5 Bitcoins.  I’ll spend the full 5, giving you 3.50, and another one of my addresses 1.50.  (Changing addresses adds to the anonymity.)  They call that “1.50” the “change”, just like if you presented a $5 bill from one pocket for a $3.50 transaction, got change back and put it into your other pocket.

OK, so you have all these transactions flying back and forth in a peer-to-peer network.  So how do you keep them all in sync and in order?   Well, each transaction has a random transaction number, so if a Bitcoin node gets a transaction, it can rapidly lookup to see if it ever got that transaction before.  If so, it can ignore this duplicate entry.  If not, it adds this transaction to the list of transactions, assuming that it looks legit (i.e. it’s a net-zero transaction – it debits the same amount that it credits, and the spending accounts are all digitally signed).  But this still doesn’t “sequence” the transactions, so wait, there’s more….

Here’s the magic part.  Again, picture the giant paper ledger at the bank.

The software is recording all these transactions on a page in the ledger.   Each transaction gets one line on the paper ledger, and each line needs to be logically consistent (i.e. net zero:  debit some accounts, credit others, for a sum of zero).  The software is also verifying that each transaction was legit, in that no money was spent that wasn’t available to be spent.  We really don’t care what sequence “on that page” the transactions are listed in, as long as we always look to previous pages to verify the account balances.  So we’ll consider all transactions on the current page as “unconfirmed transactions”.  And once we “turn the page” (moving forward in the ledger), they are confirmed.  So you can look backwards in the ledger to see confirmed transactions and make sure that the money is there to be spent.  And you can look on the current page to make sure that there aren’t two transactions that “double-spend” a balance.  And then the system can periodically “turn the page” to lock in the transactions.

So who turns the page, and what is the process of turning the page?   Well, people compete to turn the page, and get paid to do it.  They are running programs on their systems that do basically one function:  They take a group of unconfirmed transactions, and compute some math around it.  And the first one to compute the correct math gets paid.  This is the “mining” process  - another name that I dislike.

The algorithm is this:  they figuratively write one more transaction on the page that pays them a certain amount of Bitcoins (for doing the work to turn the page), and then append a “random” number on the page, and hash all the numbers on the page.  And if the hash comes up with a leading zero, then they can lock in the page.  They announce to the world that “This random number locks in page x”, and they get to keep the money, because they effectively “paid themselves” on that page.  

Of course hashing a page full of numbers to get a leading zero is not a hard problem – it’s a 50/50 shot in binary.  Hashing a page full of numbers and getting 2 leading zeros in the result is a 25% probability of success.  But hashing a page full of numbers and getting a series of 45 leading zero bits is a really hard problem.   And so the number of leading zeros required adjusts over time, depending on the success of these people who are securing the money system (called “miners”).  These people pick a random number, try the hash and fail the vast majority of the time.  But every ten minutes (on average) someone succeeds, and gets paid.

This is the way the money is initially distributed.  Those who perform this valuable service of securing the transactions get paid.

When someone announces that they have “locked a page of the ledger”, everyone else can easily check their work, and will accept it if it was done properly.  That is, verify that they paid themselves the right amount of money (which, currently, is 25 Bitcoins, but this ramps down over the years, plus any transaction fees on the page), and that the random number that they supplied truly does make the page hash to some checksum that has lots of leading zeros.

It’s a beautiful technical solution to the problem of avoiding double-spending of money.  There are some other conditions that are handled by the software as well – if two miners solve the problem nearly simultaneously, who decides who won?  Well, the overall collection of miners will proceed down both paths, with some miners believing that one person won, and others will believe that the other person won, depending on which announcement you heard first, and which answer is better in some technical tie-breaking sense.  

This probably won’t be a 50/50 split because of peer-to-peer networking, you are going to hear one first.  So, as the subsequent  page of transactions is getting locked in, different miners might be working on different problems.  And chances are that the part of the network that has more nodes believing in its path will lock the next page.  Eventually, one of the two paths will emerge victorious over the other, and one single ledger will again be considered accurate.    So the more confirmations you have on a transaction, the more “pages” have been locked in, and so the more certain you can be that it’s permanent in the ledger.  Six confirmations is considered to be perfect confirmation, in a practical sense.

Ledger Pages in my analogy are called “blocks” in Bitcoin language.

Bitcoin software and websites hide all this complexity from you.  But it helps to understand it, because it adds up to real money!  If you have a significant stash of Bitcoins, you need to know who you are trusting, and it all comes down to who is holding the Private Keys.  If you keep a balance on a website (like Blockchain.info, or Mt Gox, or Coinbase or Instawallet), then you are trusting them to protect the private keys.  This has proven to be disastrous in some other instances in the past.  But as time goes by, the weaker, less trustworthy players seem to be falling out, although someone new (trustworthy or untrustworthy) can pop up at any time, and old favorites can screw up and lose everything too!

If you are running the Bitcoin software on your local PC, then you need to protect your own private key(s).  Note that the software can generate billions of Bitcoin Addresses from one private key.  But you are trying to protect your Private Key, which is contained in a wallet file on your local PC, if you go this route.  So you would want a good backup or two of your wallet file, and you want to encrypt it.  And keep your PC free of viruses and key-loggers.

If you are holding a substantial sum of money in Bitcoins, then you may consider an offline wallet.  The concept here is to create a key pair “offline” so that no key-logger, virus, or untrustworthy website can steal your private key.  You can send money to the offline wallet without ever having the Private Key online.  If you trust bitaddress.org (and it’s all open source!), there’s a way you can print a paper wallet, and never have those digits of your private key ever appear on a pc that’s connected to the internet ever.  

And since Bitcoin is just a giant ledger, then funding that account is just a matter of paying the public key (Bitcoin Address), and you are all set.  Put your investment away for a few years and see what happens.  When you want to “spend” it or “cash” it, type in the private key (or scan it in), and you can spend it.  In fact, you can check your account balance over the years without ever having your private key touch the internet.
1713580635
Hero Member
*
Offline Offline

Posts: 1713580635

View Profile Personal Message (Offline)

Ignore
1713580635
Reply with quote  #2

1713580635
Report to moderator
1713580635
Hero Member
*
Offline Offline

Posts: 1713580635

View Profile Personal Message (Offline)

Ignore
1713580635
Reply with quote  #2

1713580635
Report to moderator
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
glub0x
Legendary
*
Offline Offline

Activity: 892
Merit: 1013



View Profile
February 07, 2013, 12:46:50 PM
 #2

From my programmer point of view, it's quite clear, i'll try.
I get some problem trying to explain to some programmer friends how btc works. Mainly i use the "it's magic" strategy to non-programmer people which is not so bad.But with programmers this doesn't work. Then it is hard to find the word to explain.
The main porblem i get with programmers is explaining the p2p part,
ledger page --> block
turning one page --> getting a nice hash starting by n 0 --> +1 confirmation
number of 0 needed in the has -> difficulty

The cost of mediation increases transaction costs, limiting the
minimum practical transaction size and cutting off the possibility for small casual transactions

Satoshi Nakamoto : https://bitcoin.org/bitcoin.pdf
DannyHamilton
Legendary
*
Offline Offline

Activity: 3360
Merit: 4570



View Profile
February 07, 2013, 06:48:34 PM
 #3

It's pretty good for trying to explain the technical aspects of bitcoin to someone that is not very technical to start with.  If I was explaining to a programmer, I'd probably have a lot more technical detail in there (depending on their level of interest).

I only had three issues I wanted to point out:

. . . A very frequent transaction that you’ll see is… say I want to give you 3.50 Bitcoins, and I have a Bitcoin Address with 5 Bitcoins.  I’ll spend the full 5, giving you 3.50, and another one of my addresses 1.50.  (Changing addresses adds to the anonymity.)  They call that “1.50” the “change”, just like if you presented a $5 bill from one pocket for a $3.50 transaction, got change back and put it into your other pocket . . .

Spending the entire contents of a previous ledger entry is not just "a very frequent transaction that you'll see".  It is a requirement of the protocol.  Using your analogy, you search back through the pages of the ledger (including the current page) to choose entries where value has been credited and you spend each of those previous credits in full.  Once the new entry is locked in (by turning the page enough times), those earlier entries that were "spent" can never again be used to fund a transaction.  To determine the current balance at a bitcoin address you add up all of the credits entries that haven't shown up yet on the debit side of the ledger.

. . . We really don’t care what sequence “on that page” the transactions are listed in, as long as we always look to previous pages to verify the account balances.  So we’ll consider all transactions on the current page as “unconfirmed transactions”.  And once we “turn the page” (moving forward in the ledger), they are confirmed.  So you can look backwards in the ledger to see confirmed transactions and make sure that the money is there to be spent . . .

It is not necessary to only look back to previous pages for "confirmed" transactions to be used to fund the credit side of the transaction.  The bitcoin protocol is perfectly fine with letting you use other credits on the same page (in the same block) to fund the debits for your current transaction.  There are some wallet programs that don't allow this, but there are some that do.

. . . Note that the software can generate billions of Bitcoin Addresses from one private key.  But you are trying to protect your Private Key, which is contained in a wallet file on your local PC, if you go this route.  So you would want a good backup or two of your wallet file, and you want to encrypt it . . .

While it is true with a deterministic wallet that billions of bitcoin adresses can be generated from a single private key, this is not how the Bitcoin-Qt wallet works.  Every time you need a new bitcoin address (including addresses used by the client for "change"), the Bitcoin-Qt wallet generates a brand new private key completely at random.  It stores all of these randomly generated private keys in the wallet file.  This means that you need to perform backups of the wallet file on a regular basis, or you will find that your old backup does not have any of the recently generated private keys that are holding most of your bitcoins.  Not having any of the recently generated private keys means you have permanently lost the ability to ever spend any of those bitcoins again.
remotemass
Legendary
*
Offline Offline

Activity: 1116
Merit: 1016


ASMR El Salvador


View Profile WWW
February 12, 2013, 09:38:01 PM
 #4

I like the use of the expression 'scan it in' instead of sweep.

Inventor of: "Conic-Upward-Jet-Thrust 𝕊ℙ𝔸ℂ𝔼 𝔼𝕃𝔼𝕍𝔸𝕋𝕆ℝ" https://archive.is/Ouxdl ¦¦ Monetize pics of in/out cash (with GPS metatag on and timestamp captions) ¦¦ archive.is/OMUJQ ¦¦ Forking LITECOIN: bitcointalk.org/index.php?topic=5362345 ¦¦ Public libraries teaching Bitcoin
jerfelix (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250


View Profile
February 12, 2013, 09:51:19 PM
 #5

I like the use of the expression 'scan it in' instead of sweep.
I was referring to scanning in the QR code.
I always thought of sweep referring to the scanning of the Block Chain looking for transactions that match your Private Key.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!