בסדרת המאמרים (חלק 1, חלק 2 וחלק 3) על פרוטוקול מטבע ביטקוין (Bitcoin) נצלול עמוק לתוך  מערכת המטבע, ממש עד המידע הגולמי ובדרך נתאר את התהליך באופן מובן ומעניין. תוכן זה מכוון לבעלי ידע בתחום המטבעות הדיגיטליים ו/או קריפטוגרפיה ו/או תכנות, במידה ואתם לא בטוחים הקליקו כאן לכל המאמרים שכדאי לדעת קודם.

טכנולוגיית הקריפטוגרפיה פתחה את הדלת לכלים ושווקים חדשים ועמם היכולת לשנות את הדרך בה אנו תופסים את הכלכלה, טכנולוגיה ואפילו התנהגות חברתית. מאחורי הקלעים עמוק בתוך הקוד פועלים מספר רכיבים יחדיו בכדי לקיים מוצר המייצג התפתחות רעיונית וגאונות אנושית. המערכת בנויה על עקרון דמוקרטי בשילוב יכולות התמודדות עם מגרעות אנושיות כגון: זיוף, גניבה וכו' אין במערכת אף רכיב המצריך לבטוח בזרים ובו בזמן אותה המערכת מאגדת זרים בכדי לבצע משימה משותפת.

הרעיון הבסיסי של ביטקוין

ביטקוין ודומיו מבוססים על קריפטוגרפיה ובעיקר על עקומים אליפטיים המשמשים להצפנה ולחתימה. קרי, יצירת ייחודיות בעולם הדיגיטלי. הסיבה העיקרית שכסף דיגיטלי הצליח רעיונית רק ב- 2008 ומעשית ב- 03/01/2009 (בלוק 0/ בלוק בראשית) היא שלפני כן לא היה קיים מכלול ששילב באופן מוצלח כלים המסוגלים להצפין ולייחד קובץ דיגיטלי.

ביטקוין מתקיים בעיקר בגלל היכולת לאבטח הודעות וליצור ייחודיות, אותם היכולות שקריפטוגרפיה ועקומים אליפטיים כאמור יודעים לעשות. למעשה, עקום אליפטי הוא הרכיב האבטחה החשוב ביותר ברשת המטבע, רכיב זה מונע התחזות, גנבות, זיופים וכו' לכן הבסיס של ביטקוין ו/או כל מטבע דומה הוא יכולות ביצוע הצפנה וייחודיות בעולם הדיגיטלי.

אכיפה ראשונית של פרוטוקול ביטקוין

מטרתה למנוע שימוש חוזר ואין סופי בקובץ דיגיטלי, זו משימה לא פשוטה כלל וכאן הייתה נעוצה הבעיה שמנעה פיתוח ושימוש מוצלח בכסף דיגיטלי. בכדי לפתח מוצר/כלי כגון ביטקוין חובה היה לפתור את הכשל הבסיסי הנ"ל, חובה היה להפוך את הקובץ לייחודי וחסין מניפולציות תוך שימוש בטכנולוגיות ויכולות מוכחות שכן אין טעם לגלות בהמשך הדרך שקיימת בעיה. באגים וטעויות אינם יכולים להתקבל בהבנה במערכת פיננסית. לצורך ההסבר נתאר תרחיש בו צד שולח וצד מקבל. נקרא לשולחת ציפי ולמקבל ביבי.

ציפי מעוניינת לשלוח מטבעות לביבי. התהליך כולו מתחיל כאשר ציפי "מפרסמת" לכולם ברשת המטבע הודעה על הפעולה שברצונה לבצע:

אני ציפי ואני מעוניינת להעביר 3 מהמטבעות שבבעלותי לביבי

עם "פרסום ההודעה" נכנס לפעולה מנגנון שמייצר רכיב המכונה הודעת שליחה חתומה (בדומה לחותמת בעולם הפיזי). בתהליך זה מיוצר גם מפתח פרטי שהוא למעשה מספר ארוך(pseudorandom)  ומורכב (256 ביט), מספר זה יכול להיות מיוצג:

  • דצימלי (Hexadecimal): 32 בייט או 64 תווים ( טווח של 0-9 + (A-F. האכיפה נעשית ע"י עקום אליפטי (ECDSA ). ספציפי עקום: Secp256k1.
  • קידוד הפלט הנ"ל מבוצע בעזרת Base-58 בכדי ליצור מספר קריא ומובן (בכדי לצמצם את האפשרות לטעויות בתווים דומים כגון 0, O וכו')
  • דוגמה למפתח פרטי: 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

עם המפתח הפרטי נוצר גם מפתח ציבורי, מהמפתח הפרטי נוצר מהמפתח ציבורי, מהמפתח הציבורי נעשית המרה לכתובת ביטקוין ע"י תמצות בעזרת: SHA-256 ו RIPEMD-160 ולבסוף המרה ל Base-58, להלן השלבים:

  • יצירת מפתח פרטי בעזרת ECDSA ,עקום: Secp256k1 בקוד ביטקוין.
  • בתהליך הנ"ל נוצר גם מפתח ציבורי ( 32בייט המקושרים לקואורדינטות על ציר X ו 32 בייט המקושרים לקואורדינטות על ציר Y שזה למעשה המיקום על העקומה Secp256k1).
  • הפלט הנ"ל (המפתח הציבורי) עובר תמצות (SHA-256).
  • הפלט של תוצאת התמצות הנ"ל עובר תהליך תמצות נוסף (RIPEMD-160).
  • לפלט הנ"ל נעשית תוספת של מספר גרסה (זיהוי טכני) בתחילתו.
  • תמצות הפלט הנ"ל שוב (SHA-256).
  • תמצות הפלט הנ"ל שוב (SHA-256).
  • 4 בייטים הראשונים של הפלט הנ"ל ישמשו כסיכום ביקורת.
  • חיבור הבייטים מהסעיף הקודם לסוף הפלט לאחר שעבר RIPEMD-160.
  • קידוד מחדש את התוצאה הנ"ל דרך Base58 בכדי שהפלט יהיה קריא למשתמש (מניעת התבלבלות בין אפס לאות O באנגלית ושאר תווים דומים).
  • דוגמה לכתובת ציבורית: 1Fu8PSHXAuAxE2hG9HZqc9mchQcETRaBRT

הידעת?

digitalmoney.co.il

מפתח ציבורי אינו כתובת ביטקוין ציבורית

הפלט של המפתח הציבורי כפי שמתואר מעל הוא הכתובת הציבורית

הערה: מפתח ציבורי אינו כתובת ביטקוין ציבורית. הפלט של המפתח הציבורי כפי שמתואר מעל הוא הכתובת הציבורית של ביטקוין.

המפתח הפרטי + כתובת ביטקוין + המידע הזקוק לחתימה = חותמת ייחודית/מידע חתום.

החתימה נגישה לכולם וכל מי שחפץ בכך יכול לוודא בעזרת המפתח הציבורי שציפי אכן חתומה על ההודעה ואף אחד אחר לא יכול היה לייצר את אותה ההודעה הספציפית הזו. חשוב לדעת: החתימה נעשית בכדי לוודא שהחותם הוא בעל המפתח הפרטי-רק דרך רכיב זה ניתן לוודא בעלות על מטבעות. ציפי לא יכולה פתאום להתכחש ולומר לא אני חתמתי (רכיב הייחודיות).

עד כאן הוספנו שיכבה שתפקידה לזהות את המען (השולח) מול רשת המטבע.

בנקודה זו לאחר פרסום ההודעה אין מה שימנע מציפי או מאחרים פשוט להעתיק את ההודעה גם אם חתומה בשלמותה ולהשתמש בה שוב ולכן בשלב זה של תיאור הפרוטוקול זיוף ומרמה הם בהחלט אפשריים שכן כל משתמש אחר יכול להעתיק ולפרסם שוב (גם ציפי בעצמה כמובן). בשלב זה יש (רק) את היכולת לוודא מי מבצע את העברה ע"י יצירת חותמת ייחודית רלוונטית לאותה העברה ולאותו המעביר בלבד אבל אין יכולת למנוע העתקה ו/או התחזות לאחר פרסומה ברבים. לכן עד כה, לפני הכנסת רכיבים נוספים הכסף הדיגיטלי הוא לא יותר מהודעת השליחה:

אני ציפי ואני מעוניינת להעביר 3 מהמטבעות שבבעלותי לביבי

יצירת ייחודיות

בשלב זה אנו יודעים שציפי רוצה להעביר מטבעות לביבי אבל אנו לא יודעים:

  • האם יש לה מספיק מטבעות? האם יש לה לפחות את הסכום אותו היא מבקשת להעביר?
  • האם זו בקשת העברה לגיטימית או ניסיון הונאה?

כאמור בשלב זה אין מה שימנע טעויות, התחזות ו/או העתקה, אין מה או מי שימנע מציפי לשלוח (בטעות או בכוונה) אין ספור פעמים את אותה הודעה, לדוגמה:

אני ציפי ואני מעוניינת להעביר 3 מהמטבעות שבבעלותי לביבי

נניח שביבי מקבל את ההודעה הנ"ל 100 פעמים.

      • האם המשמעות לכך שביבי קיבל 300 מטבעות?
      • האם המשמעות לכך שביבי קיבל 3 מטבעות?
      • האם ביבי יכול לדעת מעבר לכל ספק שציפי שלחה את ההודעה?
      • האם הוא יכול לבטוח בה?
      • האם יש לציפי לפחות 3 מטבעות?

כל עוד שאלות אלו נותרות ללא מענה משמע שאין ייחודיות ולכן אין שום ערך לתהליך כולו. בכדי להפוך את התהליך (ובכך את המיזם) לייחודי נדרש להוסיף רכיב סידרתי ספציפי וייחודי לכל הודעה ובכך ליצור הבדלה, לייחד כל הודעה, לקשר אותה למקור אחד ויחיד (בעל הממון/יוזם הפעולה) ובכך למנוע יכולת להעתיק אותה ולבצע מניפולציות, להלן הוספת ייחודיות בהמשך לדוגמה שלנו:

ציפי: הודעה מספר T8H25J6K – אני ציפי ואני מעוניינת להעביר 3 מהמטבעות שבבעלותי לביבי בשלב זה לאחר הוספת רכיב הייחודיות כולם יודעים שההודעה הנ"ל היא מקורית ואמתית, כל ניסיון להשתמש באותם הפרמטרים שוב או לבצע מניפולציות יתגלה בגלל אותו רכיב סדרתי ייחודי שהוא בלתי ניתן לשינוי. בכדי שרכיב זה יהיה חסין ויעבוד באופן מוצלח יש צורך להשתמש במקור בטוח ליצירתו וניהולו, מקור בלתי תלוי ובלתי ניתן להטיה או השפעה כלומר תהליך מתמטי טהור.

ישנה דרך מוכחת ומוכרת לכולנו בכדי להשיג זאת והיא ע"י שימוש בשרות של מתווך, לו היכולת לספק ולאכוף את הייחודיות, לדרך זו קוראים בנק (או כל שרות ריכוזי המתווך בין הצדדים). כלומר, בתנאים הללו בכדי לבצע העברה מוצלחת ובטוחה ציפי צריכה להשתמש בשירותים של בנק שיספק לה את המספר הסידורי ואת הביטחון הדרוש (ערבות). ביבי יהיה חייב להשתמש גם בשירותים של הבנק מפני שזו הדרך היחידה בה הוא יכול לקבל לידיו את הכסף שציפי רוצה לשלוח ואת הביטחון שהכול נעשה בצורה כשרה, בסוף התהליך לציפי יופחתו 3 מטבעות ולביבי יוספו 3 מטבעות, תהליך עליו אחראי מתווך שתפקידו לספק את האבטחה, לעדכן את החשבונות ולהיות ערב שאכן הכול נעשה כראוי.

אחריות קולקטיבית

בכול הקשור לביטקוין בפרט וכסף דיגיטלי בכלל אין שליטת צד ג' על הממון ואין יותר חשיבות לתפקיד המתווך, למעשה הוא מבוטל לגמרי, יכולת זו של מטבעות דיגיטליים היא הבסיס להתנגשויות בין השיטות. הרעיון הוא להפוך כל משתמש במטבע לבנק בפני עצמו כאשר אין הבדל ביכולת ההשפעה בין אחד לשני, כולם שווים, כולם מתחלקים באחריות. בכדי להשיג זאת בראש ובראשונה חובה על כל אחד מהקולקטיב להחזיק עותק מעודכן של שרשרת הבלוקים ובכך מערכת המטבע תוכל לעקוב אחר כל מטבע מרגע יצירתו ועד השימוש העדכני ביותר.

נחזור לדוגמה על ציפי וביבי, התהליך יעשה כפי שתואר מעל אבל בכדי שביבי יוכל להיות בטוח שהכול נעשה באופן כשר הוא מוודא את הודעת העברה החתומה מול שרשרת הבלוקים ואם אכן הכול נעשה כפי שצריך הוא משדר אישור לכולם, האישור הוא ההודעה המקורית של ציפי + אישור שהמטבעות הגיעו אליו. הקובץ המשותף לכולם יתעדכן מיד כאשר תהיה הסכמה על הנ"ל ע"י שאר המשתמשים. המתווך הוסר באופן מוצלח והדרך להתנהלות ישירה בין אנשים מתאפשרת כתוצאה מכך. יחד עם זאת עדיין לא ברור כיצד המספר הסידורי נוצר ואיך אפשר למנוע הונאות נוספות כגון "בזבוז כפול".

כאמור בשלב זה ציפי יכולה לשלוח (בטעות או בזדון) את אותה ההודעה עם אותו רכיב בייחודיות (המספר הסידורי) לכמה אנשים שונים ואצל כל אחד מהם יתקבל הסכום שהועבר:

ציפי:הודעה מספר T8H25J6K – להחסיר ממני 3 מטבעות ולהוסיף אותם לביבי.

ציפי:הודעה מספר T8H25J6K – להחסיר ממני 3 מטבעות ולהוסיף אותם לשימי.

ציפי:הודעה מספר T8H25J6K – להחסיר ממני 3 מטבעות ולהוסיף אותם לריקי.

ציפי שלחה את ההודעות בסדר הכרונולוגי כפי שמתואר:

  • הראשון שמקבל את ההודעה הוא ביבי והוא מאשר לרשת כולה שהכול חוקי וכשר וצריך לעדכן בכך את שרשרת הבלוקים.
  • השני שמקבל הוא שימי וגם הוא מאשר לרשת כולה שהכול חוקי וכשר וצריך לעדכן בכך את שרשרת הבלוקים.
  • השלישית שמקבלת את ההודעה עם אותה חתימה היא ריקי וגם מבחינתה הכול כשר וחוקי היא מאשרת זאת ומודיעה שצריך לעדכן את שרשרת הבלוקים.

במתואר מעל טמון כשל מערכתי בסיסי שכן לא ניתן יהיה לעדכן את שרשרת הבלוקים מכיוון שלא ניתן להגיע להסכמה מי באמת אמור לקבל את המטבעות ולכן רשת המטבע חשופה להונאות ואין ביכולה להתעדכן כראוי.

בכדי לפתור זאת, תהליך האישור כולו הפך למשותף. ביבי, שימי או ריקי לא צריכים לעדכן את רשת המטבע אלא רשת המטבע צריכה לעדכן כל עסקה וכפועל יוצא גם אותם. בפועל מי ששולח ו/או מי שמקבל מטבעות מודיע לרשת והרשת קובעת האם אותה העברה לגיטימית, חוקית וכשרה וזו בין היתר הסיבה לשמירת זמן ממוצע לעיבוד (פיצוח) בלוק (10 דקות ברשת ביטקוין) בפועל זה יישור קו ועדכון הרשת. לאחר שהרשת מגיעה להסכמה החשבון של הצדדים יעודכן. כלומר, הפחתה לציפי והוספה לביבי יחד עם עדכון שרשרת הבלוקים (רישום העסקה בקובץ המשותף לכולם). עכשיו כאשר הרשת כולה מעורבת קולקטיבית באישור העסקאות ציפי לא יכולה לשלוח את אותה ההודעה מספר פעמים או להשתמש באותו מספר סידורי/חותמת מספר פעמים, כל הרכיבים בהודעה שלה ייחודיים ונכונים לאותה הפעולה בלבד ומכיוון שכולם שותפים לפעולה אין שום דרך לשנות פרמטרים בטעות או בכוונה.

חותמת

תהליך יצירת החותמת הוא מכלול רכיבים וכולם יחד פועלים תחת: Elliptic Curve Cryptography ביטקוין עושה שימוש ב Secp256k1, להלן פרוט הרכיבים בעזרתם מיוצרת החותמת.

  • מפתח פרטי (Private Key) שהוא מספר רנדומלי הידוע רק למי שיצר אותו ורק לו תהיה גישה לממון. מספר (Unsigned Integer)  שלם טבעי (לא שלילי)  256 ביט (32 בייט). בביטקוין ובמטבעות דיגיטליים אחרים המפתח הפרטי מקושר ומותאם לשרשרת בלוקים (Blockchain) וכאמור רק מי שמחזיק במפתח הנ"ל יכול לגשת לממון שלשמו הוא נוצר[1].
  • מפתח ציבורי (Public Key) מיוצר ע"י 'עקום אליפטי' (ECDSA) ומקושר/מותאם למפתח הפרטי אבל כשמו כן הוא- ציבורי וידוע לכולם, מפתח זה משמש לקבוע האם חתימת ההודעה היא אמתית (תהליך יצירת החותמת נעשה עם המפתח הפרטי ופלט קודם) וכל זאת בלי לחשוף את המפתח הפרטי. מפתח ציבורי יכול להיות:
  • מכווץ: 33 בייט המורכב ומאותחל ב-  0x02 or 0x03, ומספר שלם טבעי (Integer) בשם X.
  • ללא כיווץ [2]: 65 בייט, המורכב ומאותחל ע"י קבוע (constant) שהוא 0x04 ולאחריו שני מספרים שלמים וטבעיים- 256 ביט (Integer) בשם X ו Y (למעשה 32 בייט כפול 2).

הרכיבים בהם נעשה שימוש עד כה באים לידי ביטוי בחלקים שונים בפרוטוקול הביטקוין:

  • מפתח פרטי (Private Key): מספר רנדומלי (256 ביט).
  • מפתח ציבורי (Public Key): מיוצר ע"י 'עקום אליפטי' (ECDSA) בעזרת המפתח הפרטי (בדר"כ "מכווץ" אך לא חייב).

הרכיבים בהם נעשה שימוש עד כה באים לידי ביטוי בחלקים שונים בפרוטוקול הביטקוין:

  • מפתח פרטי (Private Key): מספר רנדומלי (256 ביט).
  • מפתח ציבורי (Public Key): מיוצר ע"י 'עקום אליפטי'(ECDSA) בעזרת המפתח הפרטי (בדר"כ "מכווץ" אך לא חייב).

פרוטוקול ביטקוין לעומק חלק ראשון
החותמת

החותמת מוכיחה שנעשתה פעולת חתימה בהתאם לפרוטוקולים, כלומר חוקית. החותמת נוצרת ע"י מפתח פרטי/כתובת הביטקוין (בעלות/זהות החותם) והרכיב הזקוק לחתימה (הודעת העברה). החותמת עצמה היא שני מספרים הנקראים r ו s. יחד עם המפתח הציבורי וסדרת פעולות מתמטיות ניתן לקבוע שהחותמת אכן נעשתה ע"י תמצות (Hash) ומפתח פרטי (Private Key) רלוונטי וכל זאת בלי הצורך לדעת מה המפתח הפרטי. דוגמה לחתימה[3]:

IJ/17TjGGUqmEppAliYBUesKHoHzfY4gR4DW0Yg7QzrHUB5FwX1uTJ/H21CF8ncY8HHNB5/lh8kPAOeD5QxV8Xc=

נבחן את הפסקה האחרונה בעזרת הדוגמה שלנו על ציפי וביבי שלב אחר שלב מנקודת מבט של כל אחד מהם.

ציפי (מוען):

  1. ציפי מעוניינת לשלוח לביבי מטבעות.
  2. ציפי חייבת שיהיה לה ממון התואם לאותה העברה ב"ארנק דיגיטלי"/"כתובת ביטקוין" בו היא מעוניינת לעשות שימוש, ציפי והנמען חייבים כמובן להשתמש באותו סוג מטבע.
  3. ציפי חייבת לקבל את כתובת ציבורית של ביבי בכדי שיהיה לה לאן לשלוח את המטבעות.
  4. ציפי ממירה (פעולה אוטומטית) את הכתובת של ביבי למפתח ציבורי מתומצת(PubKeyHash) .
  5. ציפי מקלידה את הכתובת הנ"ל במקום המתאים (בתוכנה על המחשב, נייד או שרות צד שלישי), בלחיצה על אישור מתחיל תהליך שליחה העושה שימוש במפתח הציבורי המתומצת( PubKeyHash) בפלט (Output) של אותה השליחה, הנ"ל נחתם ע"י המפתח הפרטי כאשר המפתח הציבורי כלול בפלט ומאפשר לאחרים (כורים בין היתר) לוודא את החתימה של ציפי בלי לראות את המפתח הפרטי.
  6. אישור ראשוני (Unconfirmed Transaction) , ציפי מיד יכולה לראות שנשלחו מטבעות מהארנק/כתובת בו עשתה שימוש אל הכתובת שביבי סיפק לה אבל בשלב זה העברה עדיין צריכה לעבור את אישור הרשת כולה בכדי שהארנקים של הצדדים ושרשרת הבלוקים יעודכנו.
  7. הכורים מתמצתים את העברה הנ"ל יחד עם אחרות לתוך "בלוק "ע"י שימוש בפונקציית SHA-256. הבלוק עובר תהליך שבסופו נעשה אישור מלא להעברה הנ"ל (כל 10 דקות בממוצע) ועדכון הרשת כולה נעשה בהתאם.

ביבי (נמען):

  1. ביבי מעונין לקבל את המטבעות מציפי.
  2. לביבי חייב להיות כתובת באותה רשת המטבע של ציפי בכדי שתוכל להעביר אליו את המטבעות.
  3. ביבי מייצר כתובת ציבורית המורכבת מ: ממפתח פרטי (Private Key) שעבר המרה ליצירת כתובת ביטקוין ייחודית וציבורית (מפתח ציבורי לאחר תמצות)[4].
  4. ביבי שולח את הכתובת הציבורית לציפי. המפתח הפרטי נשאר אצלו שכן רק בעל המפתח הפרטי יכול לגשת לממון בכתובת אליה או ממנה הועברו מטבעות.
  5. אישור ראשוני (Unconfirmed Transaction) , ביבי מיד יכול לראות שנשלחו אליו מטבעות אבל העברה כולה טעונה את אשורר הרשת בכדי שהכתובת שלו/שרשרת הבלוקים יעודכנו.
  6. הכורים מתמצתים את העברה הנ"ל יחד עם אחרות לתוך בלוק ע"י שימוש בפונקציית SHA-256 , הבלוק עובר תהליך אישור להעברה הנ"ל (כל 10 דקות בממוצע) ועדכון הרשת כולה בהתאם.

עד כאן החלק הראשון של פרוטוקול ביטקוין, בשלב זה עדיין ישנם הרבה רכיבים בפרוטוקול שאינם ברורים כגון:

  • כמה אחוזים ממשתמשי הרשת זה מספיק בכדי לאשר?
  • מתי ואיך נעשה העדכון בשרשרת הבלוקים?

בחלק השני של פרוטוקול ביטקוין נתאר ונבחן את השאלות הנ"ל כולל החסרונות לשיטה כפי שהיא תוארה עד כה ואת הדרכים לתקן ולהתמודד. הקלק כאן בכדי לעבור פרוטוקול ביטקוין חלק שני.

הערות

[1] "ספר חשבונות הציבורי/שרשרת בלוקים" מחזיק בערך, ארנק יעודכן (בעזרת מפתח פרטי) כאשר בעל הארנק יחפוץ בכך, ארנק אינו חייב להיות "אונליין" אף פעם אלא רק במידה ובעליו רוצה להשתמש בערך המקושר אליו-עדכון הארנק יעשה מול שרשרת הבלוקים.

[2] בגרסאות הישנות יותר עשו שימוש בתהליך Uncompressed ליצירת כתובת, כיום הרוב עושה שימוש ב Compressed מפני שהוא יעיל וקל יותר.

[3] דוגמה לכתובת ציבורית (אמתית של ארנק): 1QKuiPibmXDNMtSNNYYmpFczZViRz9AzEF

[4] כתובת של ביטקוין נקרא גם מפתח ציבורי למרות שזה למעשה תמצות של המפתח בעזרת: SHA-256 ו RIPEMD-160 ולבסוף המרה ל Base-58. להלן התהליך המלא ליצירת כתובת ביטקוין:

  • יצירת מפתח פרטי בעזרת ECDSA
  • בתהליך הנ"ל נוצר גם מפתח ציבורי ( 32בייט) המקושרים לקורדינטות על ציר X ו 32 בייט המקושרים לקורדינטות על ציר Y שזה למעשה המיקום על העקומה.
  • הפלט הנ"ל (המפתח הציבורי) עובד תימצות .SHA-256
  • הפלט של תוצאת התמצות הנ"ל עובר תהליך תמצות נוסף ע"י .RIPEMD-160
  • תוספת של מספר גרסה (זיהוי טכני) בתחילת הפלט הנ"ל.
  • תמצות הפלט הנ"ל שוב ע"י .SHA-256
  • ושוב תמצות הפלט הנ"ל שוב ע"י .SHA-256
  • 4  בייטים הראשונים של הפלט הנ"ל ישמשו כסיכום ביקורת.
  • נחבר את הבייטים מהסעיף הקודם לסוף הפלט מסעיף 4-שזו למעשה כתובת בינארית.
  • נקדד מחדש את התוצאה הנ"ל (הכתובת) דרך Base58 בכדי שהפלט יהיה קריא למשתמש (מניעת התבלבלות בין אפס לאות O באנגלית וכו').

[5] מומלץ לקרא על "אישור ראשוני" בתהליך אישור העיסקאות.