גוף הבקשה חייב להכיל את הפרמטר הבא: 'מדינה'
XBORDER WHITEPAPER 2019

ההיסטוריה
xBORDER כמערכת מעבר מדינה
כרייה בגנרי
מרקל טריס
יישומי בלוקצ'יין אלטרנטיביים
סקריפטים של xBORDER
BLOCKCNX
פילוסופיה
חשבונות xBORDER
הודעות ועסקאות
הודעות
פונקציית מעבר מצב xBORDER
ביצוע קוד
xBORDER וכרייה
יישומים
מערכות אסימונים
נגזרים פיננסיים ומטבעות בעלי ערך יציב
מערכות זהות ומוניטין
אחסון קבצים מבוזר
ארגונים אוטונומיים מבוזרים
יישומים נוספים
שונות ודאגות
יישום GHOST שונה
עמלות
חישוב וטיורינג-שלמות
מטבע והנפקה
ריכוז כרייה
מדרגיות
סיכום
הערות וקריאה נוספת
הערות
לקריאה נוספת
מבוא לביטקוין ומושגים קיימים

הרעיון של מטבע דיגיטלי מבוזר, כמו גם יישומים חלופיים כמו רישום נכסים, קיים כבר עשרות שנים. פרוטוקולי המזומנים האלקטרוניים האנונימיים של שנות השמונים והתשעים, שנשענו ברובם על פרימיטיבי קריפטוגרפי הידוע כ-Chaumian blinding, סיפקו מטבע עם מידה גבוהה של פרטיות, אך הפרוטוקולים לא הצליחו ברובם להשיג אחיזה בגלל הסתמכותם על מתווך ריכוזי. . בשנת 1998, ה-b-money של Wei Dai הפך להצעה הראשונה להציג את הרעיון של יצירת כסף באמצעות פתרון חידות חישוביות וכן קונצנזוס מבוזר, אך ההצעה הייתה מועטה בפרטים כיצד ניתן ליישם קונצנזוס מבוזר בפועל. בשנת 2005, האל פיני הציג קונספט של הוכחות עבודה ניתנות לשימוש חוזר, מערכת שמשתמשת ברעיונות מ-b-money יחד עם חידות ה-Hashcash הקשות מבחינה חישובית של אדם באק כדי ליצור קונספט עבור מטבע קריפטוגרפי, אבל שוב נפלה מהאידיאל על ידי הסתמכות על מחשוב מהימן בתור קצה עורפי. בשנת 2009, מטבע מבוזר יושם לראשונה בפועל על ידי סאטושי נקמוטו, המשלב פרימיטיבים מבוססים לניהול בעלות באמצעות קריפטוגרפיה של מפתח ציבורי עם אלגוריתם קונצנזוס למעקב אחר מי הבעלים של מטבעות, המכונה "הוכחת עבודה".

מנגנון xBORDER מאחורי הוכחת עבודה היווה פריצת דרך בתחום מכיוון שהוא פתר בו זמנית שתי בעיות. ראשית, הוא סיפק אלגוריתם קונצנזוס פשוט ויעיל במידה, המאפשר לצמתים ברשת להסכים ביחד על קבוצה של עדכונים קנוניים למצב ה-crypto-ledger. שנית, הוא סיפק מנגנון לאפשר כניסה חופשית לתהליך הקונצנזוס, פתרון הבעיה הפוליטית של ההחלטה מי ישפיע על הקונצנזוס, ובו זמנית מניעת התקפות סיביל. היא עושה זאת על ידי החלפת חסם רשמי להשתתפות, כמו הדרישה להירשם כישות ייחודית ברשימה מסוימת, בחסם כלכלי - משקלו של צומת בודד בתהליך ההצבעה בקונצנזוס עומד ביחס ישר לכוח המחשוב. שהצומת מביא. מאז, הוצעה גישה חלופית הנקראת הוכחת הימור, המחשבת את משקלו של צומת כפרופורציונלי להחזקות המטבעות שלו ולא למשאבים חישוביים; הדיון ביתרונות היחסיים של שתי הגישות הוא מעבר לתחום מאמר זה, אך יש לציין כי ניתן להשתמש בשתי הגישות כדי לשמש עמוד השדרה של מטבע קריפטוגרפי.

​

פיטר אולדנבורגר, מייסד xBORDER כתב פוסט זה בבלוג:

​

​

קריפטו כמערכת מעבר מדינה 
ניתן להתייחס לפנקס החשבונות של מטבע קריפטו כמו הקריפטו כמערכת מעבר מדינה, שבה יש "מדינה" המורכבת מסטטוס הבעלות של כל הקריפטו הקיימים ו"פונקציית מעבר מדינה" שלוקחת מצב ועסקה. ומוציא מצב חדש שהוא התוצאה. במערכת בנקאית רגילה, למשל, המדינה היא מאזן, עסקה היא בקשה להעביר $X מ-A ל-B, ופונקציית מעבר המדינה מפחיתה את הערך בחשבון של א' ב-$X ומעלה את הערך ב-B's. חשבון על ידי $X. אם לחשבון של A יש פחות מ-$X מלכתחילה, פונקציית מעבר המצב מחזירה שגיאה. לפיכך, ניתן להגדיר רשמית:

APPLY(S,TX) -> S' או ERROR
APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
ה"מדינה" בקריפטו היא אוסף כל המטבעות (מבחינה טכנית, "פלטי עסקאות שלא הוצאו" או UTXO) שנכרו ועדיין לא הוצאו, כאשר לכל UTXO יש ערך ובעלים (מוגדרים על ידי כתובת של 20 בתים שהוא בעצם מפתח ציבורי קריפטוגרפי. 1). עסקה מכילה קלט אחד או יותר, כאשר כל קלט מכיל הפניה ל-UTXO קיים וחתימה קריפטוגרפית המופקת על ידי המפתח הפרטי המשויך לכתובת הבעלים, ויציאה אחת או יותר, כאשר כל פלט מכיל UTXO חדש שיש להוסיף אליו. המדינה.

ניתן להגדיר את פונקציית מעבר המצב APPLY(S,TX) -> S' בערך באופן הבא:

עבור כל קלט ב-TX:

אם ה-UTXO המוזכר אינו ב-S, החזר שגיאה.
אם החתימה שסופקה אינה תואמת לבעלים של UTXO, החזר שגיאה.
אם סכום הערכיות של כל הקלט UTXO קטן מסכום הערכיות של כל הפלט UTXO, החזר שגיאה.

החזר S' כאשר כל הקלט UTXO הוסר וכל UTXO הפלט נוסף.

המחצית הראשונה של השלב הראשון מונעת משולחי עסקאות להוציא מטבעות שאינם קיימים, המחצית השנייה של השלב הראשון מונעת משולחי עסקאות להוציא מטבעות של אנשים אחרים, והשלב השני אוכף שימור ערך. על מנת להשתמש בזה לתשלום, הפרוטוקול הוא כדלקמן. נניח שאליס רוצה לשלוח 11.7 BTC לבוב. ראשית, אליס תחפש קבוצה של UTXO זמינים שבבעלותה המסתכמת עד לפחות 11.7 BTC. מציאותית, אליס לא תוכל לקבל בדיוק 11.7 BTC; תגיד שהקטן ביותר שהיא יכולה לקבל הוא 6+4+2=12. לאחר מכן היא יוצרת עסקה עם שלושת התשומות ושתי הפלטים הללו. הפלט הראשון יהיה 11.7 BTC עם כתובתו של בוב כבעלים, והפלט השני יהיה ה"שינוי" הנותרים של 0.3 BTC, כאשר הבעלים היא אליס עצמה.

כריה
block_picture.jpg

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

האלגוריתם לבדיקת אם בלוק חוקי, המתבטא בפרדיגמה זו, הוא כדלקמן:

בדוק אם הבלוק הקודם אליו מתייחס הבלוק קיים והוא חוקי.
בדוק שחותמת הזמן של הבלוק גדולה מזו של ה-blockfn הקודם. שעתיים ופחות משעתיים לעתיד
בדוק שהוכחת העבודה על הבלוק תקפה.
תן S[0] להיות המצב בסוף הבלוק הקודם.
נניח ש-TX היא רשימת העסקאות של הבלוק עם n טרנזקציות. עבור כל i ב-0...n-1, הגדר S[i+1] = APPLY(S[i],TX[i]) אם אפליקציה כלשהי מחזירה שגיאה, צא והחזר false.
החזר true, ורשום את S[n] כמצב בסוף הבלוק הזה.
בעיקרו של דבר, כל עסקה בבלוק חייבת לספק מעבר מצב חוקי ממה שהיה המצב הקנוני לפני ביצוע העסקה למצב חדש כלשהו. שימו לב שהמצב אינו מקודד בבלוק בשום אופן; זוהי הפשטה גרידא שיש לזכור על ידי הצומת המאמת וניתן לחשב אותה (באופן מאובטח) עבור כל בלוק רק על ידי התחלת מצב הבראשית והחלה ברצף של כל טרנזקציה בכל בלוק. בנוסף, שים לב שהסדר שבו הכורה כולל עסקאות לתוך הבלוק משנה; אם יש שתי טרנזקציות A ו-B בבלוק כך ש-B מוציא UTXO שנוצר על ידי A, אז הבלוק יהיה תקף אם A מגיע לפני B אבל לא אחרת.

תנאי התוקף האחד הקיים ברשימה לעיל שאינו נמצא במערכות אחרות הוא הדרישה ל"הוכחת עבודה". התנאי המדויק הוא ש-Hash כפול-SHA256 של כל בלוק, המטופל כמספר של 256 סיביות, חייב להיות קטן ממטרה מותאמת דינמית, שנכון לזמן כתיבת שורות אלה הוא בערך 2187. המטרה של זה היא להפוך יצירת בלוק "קשה" מבחינה חישובית, ובכך מונעת מתוקפי סיביל ליצור מחדש את כל הבלוקצ'יין לטובתם. מכיוון ש-SHA256 תוכנן להיות פונקציה פסאודורנדומלית בלתי צפויה לחלוטין, הדרך היחידה ליצור בלוק חוקי היא פשוט ניסוי וטעייה, הגדלה שוב ושוב של ה-nonce ולראות אם ה-hash החדש תואם.

ביעד הנוכחי של ~2187, הרשת חייבת לבצע ממוצע של ~269 ניסיונות לפני שנמצא חסימה חוקית; באופן כללי, היעד מכויל מחדש על ידי הרשת כל 2016 בלוקים כך שבממוצע בלוק חדש מופק על ידי צומת כלשהו ברשת כל עשר דקות. על מנת לפצות את הכורים על עבודת החישוב הזו, הכורה של כל בלוק זכאי לכלול עסקה הנותנת לעצמם 12.5 BTC משום מקום. בנוסף, אם לכל עסקה יש ערך כולל גבוה יותר בתשומות שלה מאשר בתפוקות שלה, ההפרש מגיע גם לכורה כ"עמלת עסקה". אגב, זהו גם המנגנון היחיד שבאמצעותו מונפקים BTC; מצב הבראשית לא הכיל מטבעות כלל.

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

שלח 100 BTC לסוחר בתמורה למוצר כלשהו (רצוי מוצר דיגיטלי במשלוח מהיר)
המתן למשלוח המוצר
הפק עסקה נוספת ששולחת את אותם 100 BTC לעצמו
נסו לשכנע את הרשת שהעסקה שלו לעצמו הייתה זו שהגיעה ראשונה.
לאחר ששלב (1) התבצע, לאחר מספר דקות כורה כלשהו יכלול את העסקה בבלוק, נניח בלוק מספר 270. לאחר כשעה, יתווספו לשרשרת חמישה בלוקים נוספים לאחר אותו בלוק, כאשר כל אחד מהם אותם בלוקים המצביעים בעקיפין על העסקה ובכך "מאשרים" אותה. בשלב זה, הסוחר יקבל את התשלום כסופי ויספק את המוצר; מכיוון שאנו מניחים שמדובר במוצר דיגיטלי, האספקה היא מיידית. כעת, התוקף יוצר עסקה נוספת ושולחת את ה-100 BTC לעצמו. אם התוקף פשוט משחרר אותו לטבע, העסקה לא תעובד; כורים ינסו להפעיל את APPLY(S,TX) וישימו לב ש-TX צורך UTXO שכבר לא נמצא במדינה. אז במקום זאת, התוקף יוצר "מזלג" של הבלוקצ'יין, מתחיל בכרייה של גרסה נוספת של בלוק 270 המצביע על אותו בלוק 269 בתור אב, אך עם העסקה החדשה במקום הישן. מכיוון שנתוני הבלוק שונים, זה מצריך ביצוע מחדש של הוכחת העבודה. יתר על כן, לגרסה החדשה של התוקף של בלוק 270 יש גיבוב שונה, כך שהבלוקים המקוריים 271 עד 275 אינם "מצביעים" עליו; לפיכך, השרשרת המקורית והשרשרת החדשה של התוקף נפרדות לחלוטין. הכלל הוא שבמזלג הבלוקצ'יין הארוך ביותר נחשב לאמת, ולכן כורים לגיטימיים יעבדו על שרשרת 275 בעוד התוקף לבדו עובד על שרשרת 270. על מנת שהתוקף יהפוך את הבלוקצ'יין שלו לארוך ביותר, הוא יצטרך להיות בעל כוח חישוב רב יותר משאר הרשת גם יחד כדי להדביק את הפער (ולכן, "מתקפה של 51%").

מרקל טריס
SPV בקריפטו

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

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

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

פרוטוקול עץ מרקל הוא ללא ספק חיוני לקיימות ארוכת טווח. "צומת מלא" ברשת ה-Crypto, כזה שמאחסן ומעבד את כל הבלוק כולו, תופס כ-15 ג'יגה-בייט של שטח דיסק ברשת הביטקוין נכון לאפריל 2014, וצומח בלמעלה מג'יגה-בייט בחודש. נכון לעכשיו, זה אפשרי עבור כמה מחשבים שולחניים ולא טלפונים, ובהמשך בעתיד רק עסקים וחובבים יוכלו להשתתף. פרוטוקול המכונה "אימות תשלום מפושט" (SPV) מאפשר קיום מחלקה נוספת של צמתים, הנקראת "צמתים קלים", אשר מורידים את כותרות הבלוק, מאמתות את הוכחת העבודה על כותרות הבלוק, ולאחר מכן מורידים רק את "הענפים". " הקשורים לעסקאות הרלוונטיות עבורם. זה מאפשר לצמתים קלים לקבוע עם ערובה חזקה לאבטחה מה הסטטוס של כל עסקת ביטקוין, והיתרה הנוכחית שלהם, תוך הורדת רק חלק קטן מאוד מכל הבלוקצ'יין.

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

Namecoin - נוצר בשנת 2010, Namecoin מתואר בצורה הטובה ביותר כמסד נתונים מבוזר של רישום שמות. בפרוטוקולים מבוזרים כמו Tor, Bitcoin ו-BitMessage, צריכה להיות דרך כלשהי לזהות חשבונות כדי שאנשים אחרים יוכלו ליצור איתם אינטראקציה, אבל בכל הפתרונות הקיימים, הסוג היחיד של מזהה זמין הוא חשיש פסאודורומי כמו 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. באופן אידיאלי, אדם רוצה להיות בעל חשבון עם שם כמו "ג'ורג'". עם זאת, הבעיה היא שאם אדם אחד יכול ליצור חשבון בשם "ג'ורג'" אז מישהו אחר יכול להשתמש באותו תהליך כדי לרשום "ג'ורג'" גם עבור עצמו ולהתחזות לו. הפתרון היחיד הוא פרדיגמת ראשון לקובץ, שבה הרושם הראשון מצליח והשני נכשל - בעיה המתאימה באופן מושלם לפרוטוקול הקונצנזוס של ביטקוין. Namecoin הוא היישום הוותיק והמוצלח ביותר של מערכת רישום שמות המשתמשת ברעיון כזה.
מטבעות צבעוניים – מטרתם של מטבעות צבעוניים היא לשמש פרוטוקול המאפשר לאנשים ליצור מטבעות דיגיטליים משלהם – או, במקרה הטריוויאלי החשוב של מטבע עם יחידה אחת, אסימונים דיגיטליים, בבלוקצ'יין הביטקוין. בפרוטוקול המטבעות הצבעוניים, "מנפיקים" מטבע חדש על ידי הקצאת צבע פומבית לביטקוין UTXO ספציפי, והפרוטוקול מגדיר באופן רקורסיבי את הצבע של UTXO אחרים להיות זהה לצבע התשומות שהעסקה שיצרה אותם בילה. (כמה כללים מיוחדים חלים במקרה של קלט בצבע מעורב). זה מאפשר למשתמשים לשמור על ארנקים המכילים רק UTXO בצבע מסוים ולשלוח אותם סביב בדומה לביטקוין רגילים, במסלול אחורה דרך הבלוקצ'יין כדי לקבוע את הצבע של כל UTXO שהם מקבלים.
Metacoins - הרעיון מאחורי metacoin הוא לקבל פרוטוקול שחי על גבי הביטקוין, תוך שימוש בעסקאות ביטקוין כדי לאחסן עסקאות מטאקוין אך עם פונקציית מעבר מצב שונה, APPLY'. מכיוון שפרוטוקול metacoin אינו יכול למנוע מעסקאות מטאקוין לא חוקיות להופיע בבלוקצ'יין הביטקוין, מתווסף כלל שאם APPLY'(S,TX) מחזיר שגיאה, הפרוטוקול כברירת מחדל ל-APPLY'(S,TX) = S. זה מספק מנגנון קל ליצירת פרוטוקול מטבע קריפטוגרפי שרירותי, פוטנציאלי עם תכונות מתקדמות שלא ניתן ליישם בתוך הביטקוין עצמו, אך עם עלות פיתוח נמוכה מאוד מכיוון שהמורכבות של הכרייה והרשת כבר מטופלת על ידי פרוטוקול הביטקוין. נעשה שימוש ב- Metacoins כדי ליישם כמה סוגים של חוזים פיננסיים, רישום שמות והחלפה מבוזרת.
לפיכך, באופן כללי, קיימות שתי גישות לבניית פרוטוקול קונצנזוס: בניית רשת עצמאית ובניית פרוטוקול על גבי ביטקוין. הגישה הקודמת, על אף שהיא מוצלחת במידה סבירה במקרה של יישומים כמו Namecoin, קשה ליישום; כל יישום אינדיבידואלי צריך לאתחל בלוקצ'יין עצמאי, כמו גם בנייה ובדיקה של כל קוד מעברי המדינה ורשת הדרוש. בנוסף, אנו צופים כי מערך היישומים לטכנולוגיית קונצנזוס מבוזרת יפעל לפי חלוקת חוק כוח שבו הרוב המכריע של היישומים יהיה קטן מכדי להצדיק בלוקצ'יין משלהם, ואנו מציינים כי קיימות מחלקות גדולות של יישומים מבוזרים, במיוחד אוטונומיים מבוזרים. ארגונים, שצריכים ליצור אינטראקציה זה עם זה.

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