Volgens de wiki werd 10 minuten gekozen als “afweging”.
Waarom tien minuten specifiek? Het is een afweging die Satoshi heeft gekozen tussen de voortplantingstijd van nieuwe blokken in grote netwerken en de hoeveelheid werk die wordt verspild als gevolg van ketensplitsingen.
In het originele Satoshi-artikel wordt echter alleen uitgegaan van 10 minuten voor het berekenen van de schijfruimtevereisten.
Een block header zonder transacties zou ongeveer 80 bytes zijn. Als we veronderstellen dat blokken elke 10 minuten worden gegenereerd, 80 bytes * 6 * 24 * 365 = 4,2 MB per jaar.
Is er ergens anders een discussie waarin wordt uitgelegd hoe de blokkeringstijd van 10 minuten werd bereikt?
Opmerkingen
- Ik denk dat als de blokvereiste van 10 minuten om de een of andere reden problematisch blijkt, en de meeste miners & gebruikers zijn het daarmee eens, dit in de toekomst kan worden verlaagd.
- Mike Hearn legde me eens uit dat Satoshi de doorlooptijd van blokken schatte op 1 minuut, en koos blokintervallen van 10 minuten omdat ” 10% van het mijnbouwwerk was een behoorlijk bedrag. Momenteel is de bloktijd echter veel, veel sneller.
- @pinhead Wat bedoel je precies met het verspillen van 10% aan mijnwerk?
- @FivePoints in deze context bedoelen we dat 10 % van de gedolven blokken ” verliest de race ” tegen een ander blok dat op bijna hetzelfde moment wordt gedolven en wordt oud, wat betekent dat de subsidie wordt uitbetaald aan de mijnwerker zal nooit besteedbaar zijn en de energie die door de mijnwerker wordt verbruikt om dat blok te produceren, zal worden verspild.
- @pinhead is logisch, maar hoe werd die 10% berekend? Is het gewoon (latentie / bloktijd)?
Antwoord
Blokken van 10 minuten is gewoon een compromis.
Kortere bloktijd:
- PRO – 1 snellere bevestigingstijd (ter bescherming tegen 0-bevestig dubbele uitgaven)
- PRO – Minder uitbetalingsverschil voor miners (minder afhankelijkheid van grote pools)
- CON – Vereist grotere bandbreedte (communicatie tussen knooppunten)
- CON – Meer vorken, langere vorken en langere re-organisatietijd
- CON – Een groter deel van de ruwe hashpower wordt verspild, wat resulteert in een lagere effectieve beveiliging.
Met een langer blokinterval van langer dan 10 minuten, zouden de voor- en nadelen worden omgekeerd.
Het grote voordeel van een kortere bloktijd is de verkorte 1 bevestigingstijd. Hoewel een snellere blok “s 1 confirm transactie minder kracht heeft dan een langere block” s 1 confirm transactie, is het toch beter dan elk blok 0 bevestig de transactie.
De snelheid van eerste bevestiging lijkt misschien een enorm voordeel, maar in werkelijkheid voor de meeste transacties met een lage waarde en tijdgevoelige transacties, zoals het kopen van een kopje koffie, het betalen voor een taxi of het gebruik van een automaat, het risico op dubbele uitgaven is erg laag. Houd er rekening mee dat het accepteren van creditcards niet zonder risico is, maar verkopers hebben al lang geaccepteerd dat ze enige verliezen zullen lijden, maar als die verliezen minimaal zijn, kan dit gewoon worden gezien als een kostenpost voor het zakendoen. Zoveel handelaars zouden eenvoudig 0-confirmstransacties kunnen accepteren zonder zichzelf bloot te stellen aan meer risico dan bij creditcardfraude.
De andere factor die het reële potentieel van kortere doelblokkeringsintervallen vermindert, is dat voor veel handelaars , zelfs snellere bevestigingstijden zijn nog steeds niet snel genoeg. Voor een POS-transactie is een gemiddelde bevestigingstijd van 2 minuten nog steeds aanzienlijk langer dan wat de meeste verkopers als werkbaar beschouwen. De gemiddelde creditcardtransactie duurt ongeveer 20 seconden (inclusief vertragingen door de klant). De hele branche heeft aanzienlijke middelen besteed om zelfs maar een paar seconden af te scheren. Veranderingen zoals het door de klant laten swipen van kaart, vegen voordat alle items zijn gebeld en het niet nodig hebben van handtekeningen met een lage waarde een paar seconden besparen op een al snel proces en de kosten van die wijzigingen worden als acceptabel beschouwd om de efficiëntie van een kassa iets te verbeteren.
De andere factor is Dat het verkleinen van het doelinterval alleen de gemiddelde bevestigingstijd verkort, maar de helft ervan zal langer zijn en de staart erg lang kan zijn. Vanwege de willekeurige aard van blokoplossingen duurt ongeveer 15% van de blokken langer dan 2x het doel, 3% langer dan 3x het doel en> 7,5 minuten en ongeveer 0,5% duurt langer dan 4x het doel. Die onzekerheid maakt het voor een tijdgevoelig bedrijf moeilijk om beleidsmatig op bevestigingen te wachten. Als de meeste transacties binnen 30 seconden worden bevestigd, maar sommige minuten duren, leidt dit tot frustratie bij de klant op het verkooppunt.
Als de BTC-economie groot genoeg wordt, zouden we een uitgebreid gebruik van “groene adressen” kunnen zien om te voorzien in de behoefte aan onmiddellijke acceptatie zonder bevestigingen. Dergelijke diensten kunnen worden geleverd door grote bedrijven en worden ondersteund door een verzekering tegen fraude (tegen een kleine vergoeding per transactie). Dit zou een meer haalbare 0-confirm-oplossing zijn dan een simpele verkorting van het blokinterval.
Dat gezegd hebbende, was het doel van 10 minuten waarschijnlijk overdreven conservatief en er zijn enkele voordelen verbonden aan een kortere bloktijd.
Reacties
- Je fout is dat je denkt ” dubbele uitgaven aanval ” betekent ” 51% aanval “. U kunt proberen uw uitgaven te verdubbelen met minder, maar uw ‘ bent niet gegarandeerd van succes. Hoe meer blokken er wachten, hoe kleiner uw kans. > 50% is het punt waarop je ‘ uiteindelijk succes gegarandeerd hebt, ongeacht hoeveel blokken er worden gewacht. De kans op succes met een < aanval van 50% hangt af van het aantal blokken en niet van de hoeveelheid tijd. Dit is een voordeel van kortere blokken.
- Een kortere bloktijd heeft nog een andere voordeelloze variantie voor miners. Bovendien is de extra opslagruimte voor korte blokken verwaarloosbaar, aangezien het grootste deel van de gegevens de transacties zijn en niet de blokkoppen.
- Je hebt een aantal typefouten: de eerste 2 vermeldingen voor ” Een langere bloktijd ” moet ” CON ” en ” PRO ” in plaats van ” PRO ” en ” RRO “.
- @MeniRosenfeld Bedankt voor de correcties en ik heb variantie-verschillen toegevoegd en de opslagverschillen verwijderd als u bent correct, de verschillen zullen vrij klein zijn. Ik heb ook het op tijd gebaseerde aspect verwijderd, want hoewel ik heb gehoord dat het meer bevestigingen vereist, heb ik geen ‘ geen definitieve kennis. Er zijn genoeg andere bekende verschillen.
- Zeer mooie update, ik wou dat ik weer kon stemmen. 😉
Antwoord
Ik vond dat deel van de wiki ook frustrerend, en ik heb het zojuist bewerkt. Ik zou correcties op prijs stellen. Dit is wat ik schreef:
Tien minuten werd specifiek door Satoshi gekozen als afweging tussen de eerste bevestigingstijd en het aantal werk verspild door kettingspleten. Nadat een blok is gedolven, duurt het even voordat andere mijnwerkers erachter komen, en tot die tijd concurreren ze eigenlijk tegen het nieuwe blok in plaats van er iets aan toe te voegen. Als iemand een ander nieuw blok ontgint op basis van de oude blokketen, kan het netwerk slechts één van de twee accepteren en wordt al het werk dat in het andere blok is gegaan, verspild. Als het bijvoorbeeld gemiddeld 1 minuut nodig heeft om miners over nieuwe blokken te leren, en er komen elke 10 minuten nieuwe blokken, dan verspilt het totale netwerk ongeveer 10% van zijn werk. Door de tijd tussen blokken te verlengen, wordt deze verspilling verminderd.
Als een gedachte-experiment, wat als het Bitcoin-netwerk uitgroeit tot Mars? Vanaf de verste punten in hun banen duurt het ongeveer 20 minuten voordat een signaal van de aarde naar Mars reist. Met slechts 10 minuten tussen nieuwe blokken, zouden mijnwerkers op Mars altijd 2 blokken achter de mijnwerkers op aarde staan. Het zou voor hen bijna onmogelijk zijn om bij te dragen aan de blokketen. Als we willen samenwerken met dat soort vertragingen, zouden we minstens een paar uur nodig hebben tussen nieuwe blokken.
Reacties
Answer
Aangezien Bitcoins de eerste cryptocurrency zijn die blokgeneratie gebruikt, enzovoort, kan men aannemen dat 10 minuten een willekeurig gekozen. Elke waarde die groot genoeg was om het nieuwe blok door het netwerk te verspreiden voordat een andere mijnwerker waarschijnlijk een nieuw blok zou genereren, zou goed zijn. Aan de andere kant mogen blokken “niet te schaars zijn, aangezien het te lang zou duren om bevestigingen te krijgen. Een uur rekenen wordt als veilig beschouwd, zodat er niet mee kan worden geknoeid, dus als je die tijd in nette delen verdeelt, krijg je 10 minuten.
Er is waarschijnlijk geen discussie over dit onderwerp, aangezien de eerste Bitcoin-versie alleen door Satoshi is gemaakt, dus totdat hij zijn ware identiteit onthult of terugkomt naar de gemeenschap, kunnen de exacte redenen “niet met zekerheid worden achterhaald.
Opmerkingen
- De analyse in Satoshi ‘ s paper heeft helemaal geen ‘ betrekking op de hoeveelheid tijd die men zou moeten wachten – dat hangt uitsluitend af van de bruikbaarheid van het langdurig handhaven van een hoge hashrate tijd.Hij besprak het aantal te wachten blokken – hij liet bijvoorbeeld zien dat als de ontvanger 6 blokken wacht en de aanvaller 10% van het netwerk ‘ s hashrate, een dubbele- bestedingspoging heeft slechts < 0,025% kans om te slagen. Met 1 minuut per blok is dit 6 minuten, etc.
Antwoord
AFAICS, het enige mogelijke voordeel voor de langere bloktijd is de vermindering van de bandbreedte-overhead als gevolg van minder kans op blokketensplitsingen.
Ik betwijfel zelfs die afweging, want als de transactiegegevens de bulk zijn, is er het compenserende effect dat korter is bloktijden betekenen dat er minder gegevens moeten worden verzonden.
Ik ben zeer sceptisch dat er meer werk moet worden verspild met een kortere bloktijd, als de moeilijkheidsgraad tov de tijd om tot een consensus te komen. Wiskundig gezien verdienen de miners een percentage van de nieuw gecreëerde blokken, ongeveer evenredig met hun percentage van de hash-kracht van het systeem, ongeacht de relatieve verdeling in verhouding van hun geluk tussen werkmoeilijkheden en (de willekeurige) verweesde ketens.
Tenzij er is een bewijs, ik betwijfel de bewering dat kortere bloktijden langere tijden creëren om tot consensus te komen (dwz herorganiserende splitsingen), want als er bijvoorbeeld 4 keer meer splitsingen zijn met 1/4 van de bloktijd, zijn er ongeveer 7 meer iteraties om consensus te bereiken binnen dezelfde duur
Gezien het feit dat de onomkeerbaarheid is een functie van het aantal blokken & mdash;. ̶ niet die van tijd- en het nadeel vertragingen bij transacties, ̶ het lijkt een kortere bloktijd is ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶
ik zou het waarderen als downvoters zou op zijn minst proberen om d verdedig hun logica met een opmerking onder mijn antwoord. Dat geeft me de kans om erover te debatteren en te laten zien waarom ik denk dat ze ongelijk hebben (of mijn fout toegeven). Het punt is om ervoor te zorgen dat we collectief de juiste logica hebben.
Opmerkingen
- Dit antwoord houdt geen rekening met de tijdkosten die worden gemaakt door bloktransmissie en blokverificatie . Aangezien die tijd een ruwweg vast bedrag is voor een volledig blok, is het een groter relatief deel van een korter blokinterval dan een langer blokinterval.
- @Murch, ik schreef dat antwoord een paar dagen of weken later het begin van mijn studie van blockchains, cryptografie en Bitcoin. Mijn opvattingen zijn daardoor aanzienlijk veranderd. Aangenomen dat het transactievolume per blok wordt verminderd bij een hogere blokfrequentie, is uw claim van constante voortplanting & verificatietijd niet correct. Craig Wright beweert dat het Bitcoin-netwerk zich binnen ongeveer een seconde verspreidt naar 99% van de hashrate .
- Aangezien praktisch alle mijnwerkers zijn verbonden met Fiber en gepubliceerde gegevens suggereren dat het ‘ is net iets langzamer dan de lichtsnelheid, < 1 seconde is niet moeilijk te claimen … De belangrijkste impact dit jaar was waarschijnlijk dat mijnwerkers een upgrade hebben uitgevoerd naar een recente versie van Bitcoin Core om de segwit-activering aan te geven. Eerder dit jaar zagen we nog steeds meerdere verweesde blokken per week. Een blokkeertijd van b.v. 60 seconden zou ons terug hebben gebracht naar meerdere verweesde blokken per dag. Aangezien de gegevens er zijn om naar te kijken, is het ‘ verwarrend dat je het effect lijkt te ontkennen.
- @Murch, heeft SegWit de gemiddelde blokgrootte verkleind met een factor 10? Zo niet, dan beantwoorden de gegevens die u noemt waarschijnlijk niet aan mijn punt. Ik begrijp nu wel (niet dat ik deed in 2016 toen ik dat antwoord schreef) dat kortere bloktijden ook asymmetrische voordelen vergroten voor coalities van hashrate, zoals pools die hun winnende blokken onmiddellijk zien (geen voortplantingsvertraging). Dus buitensporige weeskinderen kunnen egoïstische mijnbouw in actie zijn. Merk op dat Ethereums variant van GHOST een gedeeltelijke oplossing is voor een deel daarvan.