Hvorfor ble blokkeringstiden valgt til å være 10 minutter?

10 minutters blokkering er rett og slett et kompromiss.

Kortere blokkeringstid:

• PRO – Raskere 1 bekreftelsestid (for å beskytte mot 0-bekreft dobbeltbruk)
• PRO – Mindre utbetalingsvarians for gruvearbeidere (mindre avhengighet av store bassenger)
• CON – Krever økt båndbredde (kommunikasjon mellom noder)
• CON – Flere gafler, lengre gafler og lengre omorganiseringstid
• CON – En større del av den rå hashkraften er bortkastet, noe som resulterer i lavere effektiv sikkerhet.

Med et lengre mål for blokkeringsintervall på mer enn 10 minutter, vil fordeler og ulemper reverseres.

Den største fordelen med en kortere blokkeringstid er redusert 1 bekreftelsestid. Mens en raskere blokk «s 1 bekrefte transaksjon har mindre styrke enn en lengre blokkering» s 1 bekrefte transaksjon, er den fortsatt bedre enn en hvilken som helst blokk 0 bekrefter transaksjonen.

Hastigheten på første bekreftelse kan synes å være en stor fordel, men i virkeligheten for mest lavverdige og tidssensitive transaksjoner som å kjøpe en kopp kaffe, betale for en taxi eller bruke en salgsautomat, risikoen for dobbeltbruk er veldig lav. Husk at å akseptere kredittkort ikke er uten risiko, men selgere har lenge akseptert at de vil møte noen tap, men hvis disse tapene er minimale, kan det bare sees på som en kostnad ved å gjøre forretninger. Så mange selgere kan ganske enkelt godta 0-bekrefte transaksjoner uten å utsette seg for større risiko enn de gjør fra kredittkortsvindel.

Den andre faktoren som reduserer det virkelige verdenspotensialet med kortere målblokkintervaller er at for mange selgere , selv «raskere» bekreftelsestider er fremdeles ikke raske nok. For en Point of Sale-transaksjon er en gjennomsnittlig bekreftelsestid på 2 minutter fortsatt betydelig lenger enn hva de fleste selgere anser for å være gjennomførbare. Den gjennomsnittlige kredittkorttransaksjonen tar omtrent 20 sekunder (inkludert forsinkelser fra kunde). Hele bransjen har brukt betydelige ressurser på å barbere seg til og med noen få sekunder. Endringer som å gjøre det mulig for kunden å sveipe kort, sveipe før alle varene er rangert, og ikke kreve signaturer med lav verdi handler om å barbere et par sekunder av en allerede rask prosess, og kostnadene ved disse endringene anses å være akseptable for å forbedre effektiviteten til kassen.

Den andre faktoren i s som reduserer målintervallet bare reduserer gjennomsnittlig bekreftelsestid, men halvparten av dem vil være lengre og halen kan være veldig lang. På grunn av den tilfeldige naturen til blokkeringsløsninger, vil omtrent 15% av blokkene ta lengre tid enn 2x målet, 3% lenger enn 3 ganger målet og> 7,5 minutter og ca. 0,5% vil ta lengre tid enn 4 ganger målet. Denne usikkerheten gjør det vanskelig for en tidssensitiv virksomhet å vente på bekreftelser. Å ha de fleste transaksjoner bekreftet på 30 sekunder, men noen tar minutter vil føre til kunde frustrasjon på salgsstedet.

Hvis BTC-økonomien vokser seg stor nok, kunne vi se utvidet bruk av «grønne adresser» for å fylle behovet for øyeblikkelig aksept uten bekreftelser. Slike tjenester kan leveres av store selskaper, og støttes av forsikring mot svindel (mot et lite pr. Transaksjonsgebyr). Dette ville være en mer levedyktig 0-bekreftende løsning enn en enkel reduksjon av blokkintervallet.

Når det er sagt, var 10-minutters målet sannsynligvis altfor konservativt, og det er noen fordeler med kortere blokkeringstid. p>

Kommentarer

• Din feil er at du tror » dobbeltbruksangrep » betyr » 51% angrep «. Du kan prøve å doble utgiftene med mindre, men du ‘ garanterer ikke suksess. Jo flere blokker ventet, jo mindre er sjansen din. > 50% er det punktet der du ‘ garanterer en eventuell suksess uansett hvor mange blokker som ventes. Sannsynligheten for å lykkes med et < 50% angrep avhenger av antall blokker og ikke hvor lang tid. Dette er en fordel med kortere blokker.
• Kortere blokkeringstid har en annen ulik variasjon for gruvearbeidere. Også den ekstra lagringsplassen for korte blokkeringer er ubetydelig siden hovedtyngden av dataene er transaksjonene, ikke blokkoverskriftene.
• Du har noen skrivefeil: De to første oppføringene for » Lengre blokkeringstid » skal være » CON » og » PRO » i stedet for » PRO » og » RRO «.
• @MeniRosenfeld Takk for rettelsene og jeg la til variansforskjeller og fjernet lagringsforskjellene som du er korrigert vil forskjellene være ganske små. Jeg fjernet også det tidsbaserte aspektet fordi mens jeg har hørt det krever flere bekreftelser, har jeg ikke ‘ ikke endelig kunnskap. Det er nok andre kjente forskjeller.
• Veldig fin oppdatering, jeg skulle ønske jeg kunne stemme igjen. 😉

Jeg fant den delen av wikien også frustrerende, og jeg redigerte den bare. Jeg setter pris på rettelser. Her er det jeg skrev:

Ti minutter ble spesifikt valgt av Satoshi som en avveining mellom første bekreftelsestid og mengden arbeid bortkastet på grunn av kjedesplitt. Etter at en blokk er utvunnet, tar det tid for andre gruvearbeidere å finne ut om den, og inntil da konkurrerer de faktisk mot den nye blokken i stedet for å legge til den. Hvis noen utvinner en ny blokk basert på den gamle blokkjeden, kan nettverket bare godta en av de to, og alt arbeidet som gikk inn i den andre blokken blir bortkastet. For eksempel, hvis det i gjennomsnitt tar gruvearbeidere 1 minutt å lære om nye blokker, og nye blokker kommer hvert 10. minutt, så kaster det totale nettverket bort 10% av arbeidet. Å forlenge tiden mellom blokkene reduserer dette avfallet.

Som et tankeeksperiment, hva om Bitcoin-nettverket vokste til å inkludere Mars? Fra de lengste punktene i banene deres tar det omtrent 20 minutter for et signal å reise fra jorden til Mars. Med bare 10 minutter mellom nye blokker, ville gruvearbeidere på Mars alltid være 2 kvartaler bak gruvearbeiderne på jorden. Det ville være nesten umulig for dem å bidra til blokkjeden. Hvis vi ønsket å samarbeide med slike forsinkelser, trenger vi minst noen timer mellom nye blokker.

Kommentarer

• Se også: bitcoin.stackexchange.com/questions/30001/…

Ettersom Bitcoins er den første kryptovalutaen som bruker blokkgenerering og så videre, kan man anta at 10 minutter var en vilkårlig valgt. Enhver verdi som var stor nok til å spre den nye blokken gjennom nettverket før en annen gruvearbeider ville være sannsynlig å generere en ny blokk, ville være bra. I den andre enden bør blokkene ikke være for knappe, da det vil ta for lang tid å få bekreftelser. En times beregning anses å være trygg fra å bli tuklet med, å dele den tiden i pene deler kan gi deg 10 minutter.

Det er sannsynligvis ikke noen diskusjon tilgjengelig om dette emnet, siden den første Bitcoin-versjonen ble opprettet av Satoshi alene, så til han avslører sin sanne identitet. eller kommer tilbake til samfunnet, kan de nøyaktige årsakene ikke bli funnet ut med sikkerhet.

Kommentarer

• Analysen i Satoshi ‘ s papir betyr ikke ‘ t i det hele tatt med tiden man skal vente – det avhenger utelukkende av det praktiske å opprettholde en høy hashrate i lang tid tid.Han diskuterte mengden blokker å vente på – han viste for eksempel at hvis mottakeren venter på 6 blokker og angriperen har 10% av nettverket ‘ s hashrate, en dobbelt- forbruk forsøk har bare < 0,025% sjanse til å lykkes. Med 1 minutt per blokk er dette 6 minutter osv.

AFAICS, den eneste mulige fordelen for jo lengre blokkeringstid er reduksjon av båndbredde overhead på grunn av mindre sannsynlighet for sperring av blokkjeder.

Jeg tviler til og med på at kompromiss, for hvis transaksjonsdataene er størst, er det motbalanseringseffekten som er kortere blokkeringstider betyr mindre data å overføre.

Jeg er veldig skeptisk til at det må bli mer bortkastet arbeid med kortere sperretid, hvis vanskeligheten er kalibrert tiden for å komme til enighet. Matematisk tjener gruvearbeiderne en prosentandel av de nyopprettede blokkene proporsjonert omtrent med prosentandelen av systemets hashkraft, uavhengig av den relative splittelsen i andel av lykken mellom arbeidsvansker og (tilfeldige) foreldreløse kjeder.

Med mindre det er et bevis, jeg tviler påstanden om at kortere sperretider skaper lengre tider for å komme til konsensus (dvs. re-org-splittelser), for for eksempel hvis det er 4 ganger flere spaltinger med 1/4 sperretid, er det omtrent 7 flere iterasjoner for å komme frem til konsensus innen samme varighet

gitt at irreversibilitet er en funksjon av antallet blokker & mDASH;. ̶ ikke tid- og ulempen forsinkelser i transaksjoner, ̶ det virker som en kortere Blokkeringstiden er ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶

i setter pris på om downvoters ville i det minste forsøker å d forbedre logikken deres med en kommentar under svaret mitt. Det gir meg en mulighet til å diskutere dem og vise dem hvorfor jeg tror de tar feil (eller å innrømme min feil). Poenget er å sørge for at vi samlet har den riktige logikken.

Kommentarer

• Dette svaret ser bort fra tidskostnadene som blokkeringsoverføring og blokkbekreftelse har pådratt seg. . Siden den tiden er omtrent et fast beløp for en full blokk, er det en større relativ del av et kortere blokkintervall enn et lengre blokkintervall.
• @Murch, jeg skrev det svaret noen dager eller uker etter initiering av studiet mitt av blokkjeder, kryptografi og Bitcoin. Mine synspunkter har endret seg betydelig derfor. Hvis du antar at transaksjonsvolumet per blokk er redusert gitt en høyere blokkfrekvens, er kravet ditt om konstant forplantning & verifiseringstid ikke riktig. Craig Wright har hevdet at Bitcoin-nettverket forplanter seg til 99% av hashratet innen omtrent et sekund.
• Siden praktisk talt alle gruvearbeidere er koblet til fiber og publiserte data antyder at det ‘ s bare litt tregere enn lysets hastighet, < 1 sekund er ikke en vanskelig påstand å gjøre … Den mest betydningsfulle effekten i år var imidlertid sannsynligvis at gruvearbeidere oppgraderte til en nylig versjon av Bitcoin Core for å signalisere for segwit-aktivering. Tidligere i år så vi fortsatt flere foreldreløse blokker per uke. En blokkeringstid på f.eks. 60 sekunder ville ha trukket oss tilbake til flere foreldreløse blokker per dag. Siden dataene er der for å se på, er det ‘ forvirrende at du ser ut til å nekte effekten.
• @Murch, reduserte SegWit den gjennomsnittlige blokkstørrelsen med en faktor 10? Hvis ikke, antar dataene du siterer, antagelig ikke mitt poeng. Jeg forstår det nå (ikke det jeg gjorde i 2016 da jeg skrev det svaret) at kortere blokkeringstider også øker asymmetriske fordeler for koalisjoner av hashrate, for eksempel bassenger som ser sine vinnende blokker umiddelbart (ingen forplantningsforsinkelse). Så overdrevne foreldreløse barn kan være egoistisk gruvedrift i aksjon. Merk Ethereums variant av GHOST er en delvis løsning på noe av det.