Varför valdes spärrtiden till att vara 10 minuter?

Enligt wiki valdes 10 minuter som ”avvägning”.

Varför tio minuter specifikt? Det är en avvägning som Satoshi väljer mellan förökningstid för nya block i stora nätverk och mängden arbete som slösas bort på grund av kedjesplittringar.

I det ursprungliga Satoshi-papperet antas dock bara 10 minuter för att beräkna diskutrymme.

Ett blockrubrik utan transaktioner skulle vara cirka 80 byte. Om vi antar att block genereras var 10: e minut, 80 byte * 6 * 24 * 365 = 4,2 MB per år.

Finns det en diskussion någon annanstans som förklarar hur 10-minuters blocktiden kom fram?

Kommentarer

  • Jag tror att om 10 minuters blockkrav visar sig vara problematiskt av någon anledning, och de flesta gruvarbetare & användare är överens, kan detta sänkas i framtiden.
  • Mike Hearn förklarade en gång för mig att Satoshi uppskattade blockutbredningstiden till 1 minut och valde 10 minuters blockintervall eftersom ” slösar bort ” 10% av gruvarbetet var en hel del. För närvarande blockerar fortplantningstiden dock mycket, mycket snabbare.
  • @pinhead Vad menar du exakt med att slösa bort 10% av gruvarbetet?
  • @FivePoints i detta sammanhang menar vi att 10 % av de utvunna blocken kommer att ” tappa loppet ” mot ett annat block som bryts nästan samtidigt och blir inaktuella, vilket innebär att utbetalningen av subventionen till gruvarbetaren kommer aldrig att användas och den energi som gruvarbetaren förbrukar för att producera det blocket kommer att slösas bort.
  • @pinhead är vettigt men hur beräknades de 10%? Är det helt enkelt (latens / blocktid)?

Svar

10 minuters block är helt enkelt en kompromiss.

Kortare blocktid:

  • PRO – snabbare 1 bekräftelsestid (för att skydda från 0-bekräfta dubbla utgifter)
  • PRO – Mindre utbetalningsvarians för gruvarbetare (mindre beroende av stora pooler)
  • CON – Kräver ökad bandbredd (kommunikation mellan noder)
  • CON – Mer gafflar, längre gafflar och längre omorganiseringstid
  • CON – En större del av den råa hashkraften slösas bort, vilket resulterar i lägre effektiv säkerhet.

Med ett längre blockintervallmål på längre än 10 minuter skulle fördelarna och nackdelarna vändas.

Den största fördelen med en kortare blocktid är den reducerade 1 bekräftelsestiden. Medan ett snabbare block ”s 1 bekräfta transaktion har mindre styrka än ett längre block” s 1 bekräfta transaktion är det fortfarande bättre än valfritt block 0 bekräftar transaktion.

Hastigheten på första bekräftelsen kan tyckas vara en stor fördel, men i verkligheten för de mest låga och tidskänsliga transaktionerna som att köpa en kopp kaffe, betala för en taxi eller använda en varuautomat, risken för dubbla utgifter är mycket låg. Kom ihåg att acceptera kreditkort inte är utan risk men säljare har länge accepterat att de kommer att möta vissa förluster men om dessa förluster är minimala kan det bara ses som en kostnad för att göra affärer. Så många handlare kunde helt enkelt acceptera 0-bekräfta transaktioner utan att utsätta sig för större risk än kreditkortsbedrägerier.

Den andra faktorn som minskar den verkliga världspotentialen med kortare målblockintervall är att för många handlare , även ”snabbare” bekräftelsestider är fortfarande inte tillräckligt snabba. För en försäljningsposition är en genomsnittlig bekräftelsestid på två minuter fortfarande betydligt längre än vad de flesta säljare anser vara användbara. Den genomsnittliga kreditkortstransaktionen tar cirka 20 sekunder (inklusive förseningar från kund). Hela branschen har spenderat betydande resurser för att raka till och med några sekunder av. Förändringar som att göra det möjligt för kunden att dra kort, svepa innan alla artiklar har rungats upp och inte kräva signaturer med lågt värde handlar rakning några sekunder av en redan snabb process och kostnaden för dessa ändringar anses acceptabla för att förbättra effektiviteten i en kassa.

Den andra faktorn i s att minska målintervallet bara minskar den genomsnittliga bekräftelsestiden men hälften av dem blir längre och svansen kan vara mycket lång. På grund av den slumpmässiga karaktären hos blocklösningar tar cirka 15% av blocken längre tid än 2x målet, 3% längre än 3x målet och> 7,5 minuter och cirka 0,5% tar längre tid än 4x målet. Denna osäkerhet gör det svårt för en tidskänslig verksamhet att vänta på bekräftelser. Att ha de flesta transaktioner bekräftade på 30 sekunder men vissa tar minuter kommer att leda till kundfrustration vid försäljningsstället.

Om BTC-ekonomin växer tillräckligt stor kan vi se utökad användning av ”gröna adresser” för att fylla behovet av omedelbar acceptans utan bekräftelser. Sådana tjänster kan tillhandahållas av stora företag och stödjas av försäkring mot bedrägerier (mot en liten per transaktionsavgift). Detta skulle vara en mer genomförbar 0-bekräftande lösning än en enkel minskning av blockintervallet.

Med detta sagt var 10-minutersmålet troligen alltför konservativt och det finns vissa fördelar med en kortare blocktid.

Kommentarer

  • Ditt misstag är att du tror att ” dubbel spendera attack ” betyder ” 51% attack ”. Du kan försöka dubbla utgifterna med mindre men du ’ garanterar inte framgång. Ju fler kvarter som väntats, desto mindre är din chans. > 50% är den punkt där du ’ garanterar eventuell framgång oavsett hur många block som väntar. Sannolikheten för framgång med ett < 50% -attack beror på antalet block och inte hur lång tid det är. Detta är en fördel med kortare block.
  • Kortare blocktid har en annan mindre variation för gruvarbetare. Det extra lagringsutrymmet för korta block är också försumbar eftersom huvuddelen av data är transaktionerna, inte blockrubrikerna.
  • Du har några stavfel: De första två posterna för ” Längre blocktid ” ska vara ” CON ” och ” PRO ” snarare än ” PRO ” och ” RRO ”.
  • @MeniRosenfeld Tack för korrigeringarna och jag lade till variansskillnader och tog bort lagringsskillnaderna som du är rätt skillnaderna blir ganska små. Jag tog också bort den tidsbaserade aspekten eftersom jag inte har ’ trots att jag har hört att det kräver fler bekräftelser. Det finns tillräckligt många andra kända skillnader.
  • Mycket trevlig uppdatering, jag önskar att jag kunde rösta igen. 😉

Svar

Jag tyckte att den delen av wiki också var frustrerande och jag redigerade den bara. Jag uppskattar korrigeringar. Här är vad jag skrev:

Tio minuter valdes specifikt av Satoshi som en avvägning mellan den första bekräftelsestiden och mängden slösat arbete på grund av kedjesplit. Efter att ett block bryts tar det tid för andra gruvarbetare att ta reda på det, och fram till dess tävlar de faktiskt mot det nya blocket istället för att lägga till det. Om någon bryter ut ett nytt block baserat på den gamla blockkedjan kan nätverket bara acceptera ett av de två, och allt arbete som går in i det andra blocket blir bortkastat. Om det till exempel tar gruvarbetare i genomsnitt 1 minut att lära sig om nya block och nya block kommer var tionde minut, slösar det totala nätverket cirka 10% av sitt arbete. Att förlänga tiden mellan block minskar detta slöseri.

Som ett tankeexperiment, tänk om Bitcoin-nätverket växte till att inkludera Mars? Från de längsta punkterna i deras banor tar det cirka 20 minuter för en signal att resa från jorden till Mars. Med bara 10 minuter mellan nya block skulle gruvarbetare på Mars alltid vara två kvarter bakom gruvarbetarna på jorden. Det skulle vara nästan omöjligt för dem att bidra till blockkedjan. Om vi ville samarbeta med sådana förseningar skulle vi behöva minst några timmar mellan nya block.

Kommentarer

Svar

Eftersom Bitcoins är den första kryptovalutan som använder blockgenerering och så vidare kan man anta att 10 minuter var en godtyckligt valt. Alla värden som var tillräckligt stora för att sprida det nya blocket genom nätverket innan en annan gruvarbetare skulle kunna skapa ett nytt block skulle vara bra. I andra änden bör block inte vara för knappa, eftersom det skulle ta för lång tid att få bekräftelser. En timmes beräkning anses vara säker från att manipuleras med, så att dela den tiden i snygga delar kan ge dig 10 minuter.

Det finns förmodligen ingen diskussion tillgänglig om detta ämne, eftersom den första Bitcoin-versionen skapades av Satoshi ensam, så tills han avslöjar sin sanna identitet eller kommer tillbaka till samhället, de exakta orsakerna kan inte räknas ut säkert.

Kommentarer

  • Analysen i Satoshi ’ papper betyder inte ’ alls inte hur lång tid man ska vänta – det beror enbart på det praktiska med att upprätthålla ett högt hashrat länge tid.Han diskuterade mängden block att vänta – han visade till exempel att om mottagaren väntar på 6 block och angriparen har 10% av nätverket ’ s hashrate, en dubbel- spend spend har bara < 0,025% chans att lyckas. Vid 1 minut per block är detta 6 minuter osv.

Svar

AFAICS, den enda möjliga fördelen för ju längre blocktid är minskningen av bandbredden på grund av mindre sannolikhet för blockkedjesplittringar.

Jag tvivlar till och med på att kompromiss, för om transaktionsuppgifterna är huvuddelen så är det motbalanseringseffekten som är kortare blocktider betyder mindre data att överföra.

Jag är mycket skeptisk till att det måste slösas mer arbete med kortare blocktid, om svårigheten är kalibrerad wrt tiden att nå enighet. Matematiskt tjänar gruvarbetarna en procentandel av de nyskapade blocken som proportioneras ungefär med deras procentandel av systemets hashkraft, oavsett den relativa fördelningen i proportion av deras tur mellan arbetssvårigheter och (slumpmässiga) föräldralösa kedjor.

Om inte det finns ett bevis, jag tvivlar på påståendet att kortare blocktider skapar längre tider för att komma fram till konsensus (dvs. re-org-splittringar), för till exempel om det finns 4 gånger fler splittringar med 1/4 blocktid, finns det ungefär 7 flera iterationer för att uppnå konsensus inom samma varaktighet

Eftersom irreversibilitet är en funktion av antalet block & mdash;. ̶ inte av tids- och nackdelen förseningar i transaktioner, ̶ det verkar en kortare blocktids är ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶

jag skulle uppskatta om downvoters skulle åtminstone försök till d förbättra deras logik med en kommentar under mitt svar. Det ger mig en möjlighet att diskutera dem och visa varför jag tycker att de har fel (eller att erkänna mitt misstag). Poängen är att se till att vi kollektivt har rätt logik.

Kommentarer

  • Detta svar bortser från tidskostnaderna för blocköverföring och blockverifiering . Eftersom den tiden är ungefär fast belopp för ett helt block, är det en större relativ del av ett kortare blockintervall än ett längre blockintervall.
  • @Murch, jag skrev det svaret några dagar eller veckor efter initiera min studie av blockkedjor, kryptografi och Bitcoin. Mina åsikter har ändrats avsevärt därför. Om du antar att transaktionsvolymen per block minskas med en högre blockfrekvens, är ditt påstående om konstant förökning & verifieringstid inte korrekt. Craig Wright har hävdat att Bitcoin-nätverket sprider sig till 99% av hashratet inom ungefär en sekund.
  • Eftersom praktiskt taget alla gruvarbetare är anslutna till fiber och publicerade data tyder på att det ’ är bara något långsammare än ljusets hastighet, < 1 sekund är inte ett svårt krav att göra … Men den mest betydande effekten i år var troligen att gruvarbetare uppgraderade till en ny version av Bitcoin Core för att signalera för segwit-aktivering. Tidigare i år såg vi fortfarande flera föräldralösa kvarter per vecka. En blocktid av t.ex. 60 sekunder skulle ha dragit tillbaka oss till flera föräldralösa kvarter per dag. Eftersom informationen finns att titta på är det ’ förbryllande att du verkar förneka effekten.
  • @Murch, minskade SegWit den genomsnittliga blockstorleken med en faktor 10? Om inte, förmodligen tar informationen du citerar inte upp min poäng. Jag förstår nu (inte att jag gjorde 2016 när jag skrev det svaret) att kortare blocktider också ökar asymmetriska fördelar för koalitioner av hashrate som pooler som ser sina vinnande block omedelbart (ingen fördröjningsfördröjning). Så överdrivna föräldralösa kan vara självisk gruvdrift i aktion. Observera Ethereums variant av GHOST är en partiell lösning på något av det.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *