כתובת ביטקוין היא מחרוזת קצרה של אותיות וספרות שמקודדת את תנאי הנעילה של סכום בשרשרת הבלוקים. קיימים לה כמה פורמטים – כאלה שמתחילים בתו 1, בתו 3, ברצף bc1q וברצף bc1p – וההבדל ביניהם נעוץ בשיטת הקידוד, באורך המחרוזת ובסוג הסקריפט שהיא מייצגת. הדף הזה מפרק כל פורמט לגורמים: איך הוא נגזר, איזו ספרת ביקורת מגנה עליו, ומה מצב התאימות בינו לבין ארנקים אחרים.
מה כתובת ביטקוין מייצגת מבחינה טכנית
ברמת הפרוטוקול עצמו לא קיים אובייקט בשם "כתובת". כל יחידה של ביטקוין נשמרת בשרשרת כפלט לא מנוצל, המכונה UTXO, ולכל פלט כזה מצורף סקריפט נעילה בשם scriptPubKey שמגדיר את התנאי לשחרור הסכום. הכתובת היא ייצוג קריא לבני אדם של אותו סקריפט: הארנק מפרק אותה בחזרה לתבנית הסקריפט המקורית לפני שהוא בונה את העסקה. בשרשרת נרשם הסקריפט בלבד – המחרוזת שהמשתמש מדביק בממשק אינה מופיעה שם באף שלב.
מכאן נובעת נקודה שמבלבלת רבים: אותה יחידת ערך יכולה להיות מוגנת בשיטות שונות לחלוטין. סקריפט אחד דורש חתימה יחידה, אחר דורש שלוש חתימות מתוך חמש, ושלישי מתנה את השחרור בחלוף פרק זמן. כל אחד מהמבנים הללו מקבל ייצוג טקסטואלי משלו, ולכן קיימת יותר מתחילית אחת.
מהמפתח הפרטי אל הכתובת
שרשרת הגזירה מתחילה במספר אקראי בן 256 סיביות – המפתח הפרטי. כפל נקודה בעקומה האליפטית secp256k1 מפיק ממנו מפתח ציבורי. על המפתח הציבורי מופעל SHA-256 ואחריו RIPEMD-160, ומתקבל תקציר בן 20 בתים המכונה HASH160. התקציר הזה, בתוספת בית גרסה בתחילתו וארבעה בתים של ספרת ביקורת בסופו, הוא מה שמקודד לכתובת מהסוג שמתחיל ב-1. כל שלב בשרשרת הוא פונקציה חד-כיוונית: אפשר לגזור כתובת ממפתח פרטי בשבריר שנייה, ואין דרך מעשית לפעול בכיוון ההפוך.
בפורמט Taproot השרשרת קצרה יותר. שם הכתובת מקודדת ישירות מפתח ציבורי בן 32 בתים בייצוג x-only, ללא שלב הגיבוב הכפול. ההבדל הזה משפיע על אורך המחרוזת ועל מבנה החתימה, שנשענת על תקן Schnorr במקום על ECDSA.
הכתובת אינה חשבון
כתובת אינה מקום אחסון ואינה מחזיקה בעצמה יתרה. היתרה שארנק מציג היא הסכום של כל הפלטים הלא מנוצלים שנעולים לטובת המפתחות שברשותו, מפוזרים על פני כתובות רבות. ארנק יחיד מנהל בדרך כלל מאות מחרוזות כאלה במקביל, וכולן נגזרות מאותו זרע. לכן הסתרת כתובת בממשק אינה משפיעה על הסכום, וגיבוי של הזרע לבדו מספיק כדי לשחזר את כולן. הסבר מפורט על מבנה הזרע ועל אופן ניהול המפתחות מופיע בדף ארנק ביטקוין.
Base58Check מול Bech32 ו-Bech32m
כל הפורמטים הקיימים נחלקים לשתי משפחות קידוד. הראשונה ליוותה את הרשת מיומה הראשון, השנייה נכנסה עם שדרוג SegWit. ההפרדה ביניהן מסבירה כמעט כל הבדל חזותי שנראה בין מחרוזת אחת לאחרת.
Base58Check
Base58 הוא בסיס מספרי שמשתמש ב-58 תווים בלבד. מהאלפבית הוסרו ארבעה תווים שקל להתבלבל ביניהם בקריאה או בהעתקה ידנית: הספרה 0, האות הגדולה O, האות הגדולה I והאות הקטנה l. גם הסימנים + ו-/ שמופיעים ב-Base64 הוצאו, כך שלחיצה כפולה על המחרוזת בוחרת אותה בשלמותה.
הגרסה המורחבת, Base58Check, מוסיפה שני רכיבים למטען. הראשון הוא בית גרסה בתחילתו, שקובע איזו תחילית תתקבל בפועל: ערך 0x00 מפיק מחרוזת שפותחת בספרה 1, וערך 0x05 מפיק מחרוזת שפותחת בספרה 3. הרכיב השני הוא ספרת ביקורת באורך ארבעה בתים, המחושבת כארבעת הבתים הראשונים של SHA-256 המופעל פעמיים על המטען. הקידוד הזה רגיש לאותיות גדולות וקטנות – שינוי של אות בודדת מגודל לקטן פוסל את המחרוזת כולה.
Bech32 ו-Bech32m
Bech32 הוגדר במסמך BIP 173 ונכנס לשימוש יחד עם SegWit. מבנה המחרוזת מחולק לשלושה: חלק קריא בשם HRP, שערכו bc ברשת הראשית; תו מפריד יחיד 1; ואחריו חלק הנתונים. אלפבית הנתונים מונה 32 תווים ואינו כולל את 1, את b, את i ואת o. ששת התווים האחרונים במחרוזת הם קוד BCH המשמש לגילוי שגיאות.
התו הראשון בחלק הנתונים מקודד את גרסת העד. הערך q מייצג גרסה 0, ומכאן התחילית bc1q. הערך p מייצג גרסה 1, ומכאן התחילית bc1p. Bech32m, שהוגדר במסמך BIP 350, זהה במבנהו אך משנה קבוע יחיד בחישוב ספרת הביקורת מהערך 1 לערך 0x2bc830a3. השינוי נדרש לאחר שהתגלתה חולשה בגרסה המקורית: כאשר התו האחרון במחרוזת הוא p, הוספה או השמטה של תווי q שלפניו אינה נקלטת כשגיאה. הפרדת הקבועים מבטיחה שמחרוזת של גרסת עד 1 ומעלה לא תעבור אימות תחת הכללים הישנים, ולהפך.
הפורמטים לפי תחילית
ארבע התחיליות הנפוצות ברשת הראשית מסודרות כאן לפי סדר הופעתן ההיסטורי. התחילית היא הסימן המיידי לזיהוי – היא חושפת גם את משפחת הקידוד וגם את סוג הסקריפט שמאחוריה.
מפענח פורמטים של כתובות
| תחילית | שם הפורמט | קידוד | נכנס לשימוש |
|---|---|---|---|
1 |
P2PKH – Legacy | Base58Check | 2009 |
3 |
P2SH – כולל SegWit עטוף | Base58Check | 2012 |
bc1q |
P2WPKH / P2WSH – SegWit נייטיב | Bech32 | 2017 |
bc1p |
P2TR – Taproot | Bech32m | 2021 |
כתובות Bech32 נכתבות באותיות קטנות בלבד ומכילות ספרת ביקורת, כך שטעות הקלדה בודדת נתפסת עוד לפני שידור העסקה.
הפענוח מקומי בדפדפן, אינו בודק יתרות ואינו המלצה לפעולה.
מחרוזת מסוג 1… מייצגת סקריפט P2PKH – נעילה מול תקציר של מפתח ציבורי יחיד. אורכה לרוב 34 תווים, ולעיתים נדירות מעט פחות, משום שאפסים מובילים במטען מתקצרים בקידוד. זהו הפורמט היחיד שהיה קיים בשנים הראשונות.
מחרוזת מסוג 3… מייצגת סקריפט P2SH ואורכה תמיד 34 תווים. במקום לנעול מול מפתח, היא נועלת מול תקציר של סקריפט פדיון שלם. הצד ששולח אינו יודע מה מסתתר מאחוריה: אותה תחילית משמשת גם למבנה רב-חתימה, גם לנעילה מבוססת זמן וגם ל-SegWit עטוף, שבו פלט SegWit נארז בתוך מעטפת P2SH כדי לשמור על תאימות עם תוכנה ישנה. תוכן הסקריפט נחשף רק כשהסכום משוחרר בפועל.
מחרוזת מסוג bc1q… מייצגת SegWit נייטיב בשתי גרסאות: אורך של 42 תווים מציין P2WPKH, כלומר נעילה מול מפתח יחיד, ואורך של 62 תווים מציין P2WSH, כלומר נעילה מול תקציר של סקריפט. מחרוזת מסוג bc1p… באורך 62 תווים מייצגת P2TR, מבנה Taproot שהופעל בנובמבר 2021.
ברשתות בדיקה התחיליות שונות לגמרי: tb1 ברשת הבדיקה הציבורית, bcrt1 בסביבת regtest מקומית, וכן m או n ו-2 עבור המקבילות בקידוד Base58Check. הפרדה זו מונעת שליחה מוטעית בין הרשתות.
לבחירת הפורמט יש השפעה ישירה על משקל העסקה, ומכאן על העמלה. הטבלה מסכמת את הנתונים המרכזיים; המספרים מעוגלים ומשתנים מעט לפי מבנה החתימה בפועל.
| סוג סקריפט | תחילית | אורך אופייני | גודל פלט | משקל קלט משוער |
|---|---|---|---|---|
| P2PKH | 1… |
34 תווים | 34 בתים | ~148 vB |
| P2SH עם SegWit עטוף | 3… |
34 תווים | 32 בתים | ~91 vB |
| P2WPKH | bc1q… |
42 תווים | 31 בתים | ~68 vB |
| P2WSH | bc1q… |
62 תווים | 43 בתים | תלוי בסקריפט |
| P2TR במסלול מפתח | bc1p… |
62 תווים | 43 בתים | ~58 vB |
ההפרש נובע מהאופן שבו SegWit מפריד את נתוני החתימה משאר העסקה ומעניק להם משקל מופחת בחישוב. פירוט מלא של אופן חישוב העמלה מופיע בדף עמלות ביטקוין.
תאימות בין ארנקים
שליחה מול קבלה
התאימות אינה סימטרית, וזו נקודת הבלבול הנפוצה ביותר. ארנק יכול להפיק רק מחרוזות מהסוגים שהוא יודע לגזור, ולכן צד מקבל שתוכנתו ישנה פשוט לא יציג אף פעם מחרוזת bc1p. בצד השליחה המצב שונה: כדי לשלוח לפורמט חדש, התוכנה השולחת צריכה לדעת לפרק אותו. תוכנה שנכתבה לפני 2017 עשויה לדחות מחרוזת bc1q כלא תקינה, אף שהיא תקינה לחלוטין מבחינת הרשת.
המעטפת מסוג 3… נועדה בדיוק לפער הזה. היא מאפשרת לצד המקבל ליהנות מהמשקל המופחת של SegWit, בעוד הצד השולח רואה תחילית ישנה שהוא יודע לטפל בה מאז 2012. כיום רוב התוכנות תומכות בכל ארבעת הפורמטים, והמעטפת נשארת בעיקר כפתרון לממשקים ישנים.
חשוב להפריד בין דחייה לבין אובדן. תוכנה שאינה מזהה תחילית תסרב לבנות את העסקה מלכתחילה, ולכן שום סכום אינו יוצא לדרך. הכשל מתרחש בשלב האימות המקומי, לפני שידור לרשת.
מסלולי גזירה וקידומות של מפתח מורחב
ארנקים היררכיים פועלים לפי תקן BIP 32, ולכל פורמט הוקצה מסלול גזירה ייעודי. המסלול m/44'/0'/0' מוליד מחרוזות 1…, המסלול m/49'/0'/0' מוליד 3… עם SegWit עטוף, המסלול m/84'/0'/0' מוליד bc1q… והמסלול m/86'/0'/0' מוליד bc1p…. אותו זרע בדיוק מייצר ארבע קבוצות נפרדות לגמרי של מחרוזות.
מכאן נובעת תופעה שנראית מבהילה: שחזור זרע בתוכנה שברירת המחדל שלה היא מסלול אחר מציג יתרה אפסית, אף שדבר לא אבד. הנתונים ממתינים במסלול שלא נסרק, והצגתם דורשת הוספה ידנית של המסלול הנכון. גם קידומות המפתח המורחב – xpub, ypub ו-zpub – הן רק סימון לפי SLIP-132 לאותו מפתח, ואינן מידע קריפטוגרפי נוסף. התקן המודרני מעדיף במקומן תיאור פלט מפורש, שכולל את תבנית הסקריפט ואת המסלול במחרוזת אחת חד-משמעית.
ספרת ביקורת ואותיות קטנות
שתי משפחות הקידוד מגנות מפני טעויות הקלדה, אך בעוצמה שונה. ב-Base58Check ספרת הביקורת תופסת 32 סיביות, ולכן ההסתברות שמחרוזת פגומה אקראית תתקבל כתקינה היא כאחת ל-4,294,967,296. ההגנה סטטיסטית באופייה ואינה מצביעה על מיקום הפגם.
Bech32 ו-Bech32m מציעים הגנה מסוג אחר. ששת תווי הביקורת מהווים קוד לגילוי שגיאות שמאתר בוודאות כל פגיעה בעד ארבעה תווים, ובמקרים חמורים יותר ההסתברות לקבלה שגויה נמוכה מאחת למיליארד. חלק מהתוכנות אף מסמנות למשתמש את התו החשוד.
נושא האותיות מבלבל לעיתים קרובות. מחרוזת Bech32 תקפה כשהיא כתובה כולה באותיות קטנות או כולה באותיות גדולות, אך ערבוב בין השתיים פוסל אותה. הממשקים מציגים כמעט תמיד את הגרסה הקטנה, בעוד הגרסה הגדולה שמורה לקודי QR: מצב הקידוד האלפאנומרי של QR כולל אותיות גדולות בלבד, ולכן ייצוג כזה מפיק קוד צפוף ונוח יותר לסריקה. אצל Base58Check, לעומת זאת, גודל האות הוא חלק מהנתון עצמו ואסור לשנותו.
שתי הבהרות מעשיות נוספות: תווים ריקים שנדבקים בהעתקה אינם חלק מהמחרוזת ויש להסירם, והתו 1 בתוך bc1… אינו חלק מהנתונים אלא מפריד – המפריד הוא המופע האחרון של התו הזה במחרוזת.
כתובות חד-פעמיות, כתובת עודף ושגיאות שליחה
ארנק היררכי גוזר מחרוזת חדשה בכל בקשת תשלום, והמחרוזות הקודמות נשארות תקפות ללא הגבלת זמן. הסריקה בשחזור נעצרת אחרי רצף של עשרים מחרוזות ריקות ברציפות – מגבלה המכונה gap limit – ולכן פילוג ידני של תשלומים על פני מחרוזות מרוחקות עלול להשאיר נתונים מחוץ לטווח הסריקה.
שימוש חוזר באותה מחרוזת אינו פוגם בתקינות הטכנית, אך הוא מקשר בין תשלומים נפרדים תחת מזהה יחיד וגלוי לכל. הרחבה על ההיבט הזה מופיעה בדף האם ביטקוין אנונימי.
כתובת העודף
פלט לא מנוצל נצרך תמיד בשלמותו. כאשר הסכום הנדרש קטן מהפלט הזמין, הארנק יוצר פלט שני שמחזיר את ההפרש לעצמו – זוהי כתובת העודף, הנגזרת מענף פנימי נפרד באותו עץ מפתחות. התהליך אוטומטי לחלוטין, ולכן הופעת מחרוזת לא מזוהה בפירוט העסקה אינה תקלה. אם פלט העודף מושמט בטעות בבנייה ידנית, ההפרש כולו נזקף לעמלת הכורה ואינו ניתן להשבה.
מה קורה בשליחה לכתובת שגויה
התרחיש הנפוץ הוא שגיאת הקלדה. במקרה כזה ספרת הביקורת אינה מסתדרת, התוכנה מסרבת להמשיך, ולא נוצרת עסקה כלל. זהו המצב הבטוח מבין כל האפשרויות.
תרחיש שני הוא מחרוזת תקינה לחלוטין ששייכת לגורם אחר. הרשת מאמתת אך ורק את התאמת הסקריפט, ואין בה מנגנון של ביטול או השבה. אין גוף מרכזי שיכול להפוך את הרישום, והשבה תלויה כולה ברצונו הטוב של המקבל.
תרחיש שלישי הוא מחרוזת של רשת אחרת. חלק קריא שאינו bc נדחה מיידית על ידי תוכנה שפועלת ברשת הראשית, ולכן טעות בין רשת בדיקה לרשת ראשית נחסמת בשלב האימות. לעומת זאת, שרשראות אחרות שאימצו מבנה קידוד דומה עלולות ליצור מחרוזות שנראות דומות מאוד, וסכום שנשלח לסקריפט שאיש אינו מחזיק במפתח שלו נשאר נעול לצמיתות.
שלוש פעולות מפחיתות את הסיכון בפועל: השוואת הקבוצה הראשונה והאחרונה של התווים לאחר ההדבקה, שימוש בסריקת QR במקום בהקלדה, והעברה ראשונה בסכום זעום לפני העברה גדולה. תוכנות זדוניות שמחליפות את תוכן הלוח מסתמכות בדיוק על כך שהמחרוזת ארוכה מכדי שמישהו יטרח לבדוק אותה.
שאלות נפוצות
מה ההבדל בין כתובת שמתחילה ב-1 לכתובת שמתחילה ב-bc1q?
שתיהן נועלות סכום מול מפתח ציבורי יחיד, אך בקידוד שונה ובמבנה עסקה שונה. הראשונה משתמשת ב-Base58Check ומייצגת סקריפט P2PKH, והשנייה משתמשת ב-Bech32 ומייצגת P2WPKH. הצורה השנייה תופסת פחות מקום בבלוק, ולכן משקל הקלט שלה נמוך יותר.
האם אפשר לשלוח מכתובת ישנה לכתובת bc1p?
הרשת מאפשרת זאת ללא כל מגבלה – סוג הקלט וסוג הפלט בלתי תלויים זה בזה. המחסום היחיד הוא תוכנת השליחה: גרסה שאינה תומכת ב-Bech32m תדחה את המחרוזת בשלב האימות המקומי. עדכון התוכנה או שימוש בממשק אחר פותרים זאת, ולא נדרשת המרה של הסכום עצמו.
מדוע כתובת Bech32 מוצגת באותיות קטנות?
התקן מגדיר את שתי הצורות כתקפות, אך אוסר על ערבוב ביניהן באותה מחרוזת. אותיות קטנות נבחרו כברירת המחדל להצגה מפני שהן קריאות יותר ומקטינות טעויות העתקה. הצורה באותיות גדולות משמשת בעיקר בתוך קודי QR, שם היא מפיקה קוד קטן וצפוף יותר.
מה קורה אם מקלידים תו שגוי בכתובת?
ספרת הביקורת המשובצת בכל הפורמטים לא תסתדר, והתוכנה תסמן את המחרוזת כלא תקינה עוד לפני בניית העסקה. ב-Bech32 ו-Bech32m האיתור ודאי כאשר נפגעו עד ארבעה תווים. שום סכום אינו מועבר בשלב הזה, ולכן טעות הקלדה בפני עצמה אינה גורמת לאובדן.
החומר בדף זה הוא הסברי-טכני בלבד, נועד לתיאור אופן פעולתו של הפרוטוקול ואינו המלצה לפעולה מכל סוג.
להרחבה בנושאים קרובים: מדריך ביטקוין המלא · ארנק ביטקוין · האם ביטקוין אנונימי · עמלות ביטקוין
