Taproot sulautettiin Bitcoin Core -ohjelmaan lokakuussa 2020, jättäen vain aktivointimenetelmän tälle odotetulle protokollapäivitykselle, joka keskittyi älykkään sopimuksen joustavuuden ja liiketoiminnan yksityisyyden lisäämiseen Bitcoiniin.

Viime viikolla Bitcoin-kehitysyhteisö kokoontui Internet Relay Chat (IRC) -palvelun kautta keskustelemaan Taproot-aktivoinnin parametreista ja BIP 8 -merkintämekanismin kahdesta koodinvetopyynnöstä (PR)..

“Pyrimme saamaan tämän lähemmäksi maalilinjaa järjestämme IRC-kokouksen ## taproot-activation -kanavalla tiistaina 2. helmikuuta kello 19:00 UTC”, Bitcoinin kehitysjärjestäjä Michael Folkson ilmoitettu bitcoin-dev-postituslistalla. “Ensisijaisena tavoitteena on viimeistellä tarkistettu BIP 8 -aktivointimenetelmä …”

Viime kädessä tämä kokous antoi enemmän tietoa siitä, kuinka Bitcoinin merkittävin protokolla muuttuu, koska SegWit saattaa siirtyä eteenpäin.

Toimittajan huomautus: Alla olevista IRC: stä toistettuja lausuntoja on muokattu hieman selkeyden vuoksi, mutta ne on muuten esitetty sellaisina kuin ne on kirjoitettu.

Antaa muodon ehdotukselle

Bitcoin-kehittäjä Anthony Towns on koonnut ehdotuksia ja mahdollisia skenaarioita Taprootin aktivoimiseksi. 2. helmikuuta pidetyssä kokouksessa, eniten tukea näyttävät olevan ”BIP 8 (väärä, 1v)” ja “BIP 8 (tosi, 1v)”. Äänestystä ei kuitenkaan annettu, vaan keskusteltiin vain jokaisesta vaihtoehtoisesta aktivointimenetelmästä.

Mutta mitä tämä tarkoittaa? BIP 8 on mekanismi, joka mahdollistaa yhteisymmärryksen päivittämisen Bitcoin-verkossa pehmeän haarukan ja erityisesti kaivostyöläisten aktivoiman pehmeän haarukan tai MASF: n avulla, jolla on mahdollisuus lisätä käyttäjän aktivoitu pehmeä haarukka (UASF) jonkin ajan kuluttua. Viimeisessä konsensuspäivityksessä (SegWit) BIP 9: n MASF: n lisäksi käytettiin käyttäjän aktivoimaa pehmeää haarukkaa (UASF). Taproot ei kuitenkaan näytä olevan kiistanalainen kaivostyöläisille, joten näyttää epätodennäköisemmältä, että UASF olisi tällä kertaa tarpeen.

Palataksemme ehdotukseen, parametrit ovat “lockinontimeout” ja “timeout”, joissa lockinontimeout tarkoittaa periaatteessa sitä, pakotetaanko aktivointi vai ei, ja “timeout” tarkoittaa ikkunaa, jossa se aktivoitaisiin. Toinen asiaankuuluva parametri, josta ei keskusteltu tarpeeksi, oli “startheight”.

Jos lockinontimeout on väärä eikä päivityksellä ole tarpeeksi tukea, se peruutetaan ja määritetään uusi ehdotus. (Bitcoin-kehittäjä Luke Dashjr kuvaili lockintimeout = false antavan kaivostyöläisille lisävaltaa, jota heillä ei koskaan ollut tarkoitus olla),

“Jos aloitat (aikakatkaisu = T, lockinontimeout = epätosi), on kolme mahdollisuutta, kun T osuu: aktivointi epäonnistuu, yrität uudelleen uudella aktivoinnilla (aikakatkaisu = T + 1 vuosi, lockinontimeout = tosi, esim.); ennen sitä käsket kaikkia vaihtamaan ohjelmistonsa (aikakatkaisu = T, lockinontimeout = tosi), jolloin olet päivittänyt MASF: n UASF: ksi “, Towns kirjoitti IRC: llä. “On myös mahdollista saada kaikki päivittämään ohjelmistoon, joka määrittää (aikakatkaisu = T-6 kuukautta, lockinontimeout = tosi), jolloin päivitetyt ihmiset alkavat hylätä lohkoja T-6kuukaudessa ja jos pisin ketju aktivoituu siihen mennessä sekä vanhoissa että uusissa ohjelmistoissa on pehmeä haarukka aktivoituna. “

Dashjr on kuitenkin eri mieltä lockinontimeout = false:

“… olemmeko tyytyväisiä lockingtimeout = epätosi yleensä?”, Bitcoin Developer Maxim Orlovsky kysyi.

“Kyllä”, Lightning Developer Rusty Russell vastasi. “Meillä on UASF-vasara, jos tarvitsemme sitä, mutta on parempi olla käyttämättä sitä.”

“Lot = true ei tarkoita, että käytämme sitä, lot = false tarkoittaa, että tarkoituksena on antaa kaivostyöläisten päättää”, Dashjr kirjoitti. “BIP8 (väärä) on regressio.”

Mutta Russell vastusti sitä, mitä hän näkee kehittäjien määräämänä: “Minusta on tärkeää, että kehittäjän toimeksiannon välttäminen protokollaa kohtaan on tärkeää, ja pidän myös siitä, että minulla olisi pakoportti, jos ongelmia löydettäisiin ennen aktivointia”, hän kirjoitti. “Siksi aloitan mieluummin lockin = false, ja palaan takaisin kuuden kuukauden kuluttua, jos se ei ole aktivoitunut.”

“Kehittäjän toimeksiantoa ei ole … on järkevämpää tehdä 1y, väärä sitten 1y, totta samalle 1v-jaksolle [kahden seuraavan käyttöönoton tapauksessa]”, Dashjr vastasi.

Mutta Russell ei näyttänyt heiluvan:

“Olen eri mieltä”, hän kirjoitti. “Kaivostyöläiset saavat koordinointivaltaa, koska voimme mitata ne luotettavasti hajautetusti toisin kuin muut ryhmät. Tämä tarkoittaa kykyä * ei * koordinoida, kyllä. Mutta meillä on myös suunnitelma sitä varten, koska BIP-8 tekee UASF: stä paljon vähemmän todennäköisesti hajoamisen. Se on niin hyvä kuin voimme tehdä. “

“Lot = true IS suunnittelee sitä”, Dashjr kirjoitti vastauksena, “se ei estä kaivostyöläisiä tekemästä MASF: ää.”

Muut chat-jäsenet ehdottivat, että lockinontimeout = false olisi valinnainen, mutta oletus:

“Lot = false on turvallisempi kuin lot = true, joten kannattaa tehdä lot = false ensin, koska tiedämme, että hashpower on ~ 90% jo pro-taproot”, kirjoitti CoinSwap-kehittäjä Chris Belcher.

IIF-käyttäjät voivat helposti vaihtaa erän = väärä arvoksi arvoksi = tosi jossakin vaiheessa tarvitsematta uutta ydinjulkaisua. Keagan McClelland kirjoitti.

UASF-vasara

Selventää:

BIP8 w / LockinOnTimeout on MASF w / UASF -varalähde.

Niin kauan kuin kaivostyöläiset aktivoituvat, UASF: ää ei tapahdu.

Ennalta suunniteltu UASF varmistaa myös, että MASF tapahtuu:

Se välttää kaivostyöläisten veto-oikeuden antamisen ja luo asianmukaisen kannustimen varmistaa MASF: n esiintyminen.#Bitcoin #Taproot

– Luke Dashjr (@LukeDashjr) 2. helmikuuta 2021

Dashjr haluaa käyttää “BIP 8 (true)” -tapahtumaa, UASF: n varavoimaa, peliteorian laitteena varmistaakseen, että kaivostyöläiset aktivoivat Taprootin, eikä anna heille mitään mahdollisuutta “veto-oikeuteen”, aivan kuten mitä SegWitin kanssa tapahtui..

“Kun otetaan huomioon merkinantovaatimukset, minkä tyyppisen pysähdys- tai suruhyökkäyksen kaivosallas voisi saavuttaa, jos he arvostavat katkoviivan jumiutumista?” käyttäjä, jota kutsutaan hansikkaaksi, kysyi IRC: ssä 2. helmikuuta. “Esimerkiksi aktivointiin tarvittavan marginaalisen hashraten väärinkäyttö.”

Muistutuksena on, että signaloinnilla pyritään vähentämään haarukkariskejä, eikä sillä ole mitään tekemistä poliittisen tuen tai äänestyksen kanssa.

“MASF on ensisijainen polku, jossa UASF on varavara, jos kaivostyöläiset eivät anna signaalia”, Dashjr kirjoitti takaisin. “Yhteisö voi siirtää UASF: n aikaisemmin, jos on selvää, että joku estää sen.”

PR 1020 ja 1021

Jotta BIP 8 toimisi, sitä olisi muutettava. Tämä merkitsee muutoksia merkinantomekanismiin, ja nämä ovat koodin PR: t, jotka pyrkivät tekemään niin:

  • 1020: Tekisi kaivosmiehistön merkitsemisen tarpeettomaksi LOCKED_IN-vaiheen jälkeen, koska tässä vaiheessa pehmeä haarukka aktivoituu varmasti.
  • 1021: Salli joidenkin MUST_SIGNAL-lohkojen olla ilmoittamatta.

1020 oli saanut tunnustuksen 2. helmikuuta pidetyssä kokouksessa, ja vuotta 1021 pidettiin aluksi tarpeettomana.

“Ok, joten 1021 on merkityksellinen vain silloin, kun kaivostyöläiset EI ole aktivoinut haarukkaa”, Dashjr kirjoitti. “1021 on VAIN UASF-skenaariossa … se sallii jopa 5%: sta lohkoista puuttuvan vaaditun signaalin … IMO on turha ja vain lisää monimutkaisuutta.”

Mutta myöhemmin vaihdossa, Blockstream-tutkija Nick Jonas huomautti, että 1021 voi olla tarpeen.

“Re # 1021, jos päätät ajaa bip8 (tosi) niin, että useimmat solmut suorittavat edelleen bip8 (väärä), et todellakaan ajaa koodia, joka ei toteuta # 1021, koska saatat muuten joutua väärään ketjuun”, Jonas kirjoitti.

“Nickillä on vahvuus”, Dashjr vastasi myöhemmin IRC: ssä. “Ilman 1021: tä voit suorittaa LOT = true ja olla noudattamatta Taproot-aktivoitua ketjua!”

Toisessa näille PR-merkitykselliselle vaihdolle Towns huomautti, kuinka nämä PR: t voisivat olla merkityksellisiä huonojen toimijoiden potentiaalin kannalta.

“(1) perustelu on tässä, että UASF: n aikana signalointivaatimukset aiheuttavat ketjun halkeamisen riskin – jos lohko ei signaloi, ei-UASF-kaivosmies rakentaa sitä, mutta kaikki tietävät, että molemmat lohkot hylätään, joten se on hyökkääjien mahdollisuus tuplata kulutusta. hyväksymällä mahdollisimman monta ei-signalointilohkoa (eli enintään 5%), tämä hyökkäys rajoittuu ”, Towns kirjoitti. “(2) toinen näkökohta on, jos aloitat pidemmällä aikakatkaisulla (aikakatkaisu = 2 vuotta, lockinontimeout = tosi / väärä) ja sitten haluat nopeuttaa aktivointia, koska kaikkien päivitetyt, markkinat sanovat haluavansa sitä, ja siellä on 6% kaivostyöläisistä, jotka yrittävät vakuuttaa kaikki, että bitcoin imee, ja meidän pitäisi siirtyä toiseen ketjuun, sitten voimme asettaa (aikakatkaisu = 1 vuosi, lockinontimeout = tosi). “

“Mutta nämä kaivostyöläiset aiheuttavat ongelman, kun olemme kuitenkin saavuttaneet 5%, eikö?” Dashjr kysyi.

“Luo ongelma, kun olemme saavuttaneet 5%” – kyllä, Towns vastasi, “jos on >kaivostyöläiset voivat aiheuttaa ongelman; jos on vain noin 2%, niin vältetään ongelman syntyminen, jos teemme lyhyemmän aikakatkaisun lukituksella timeout = true, niin jos saavutamme aikakatkaisun ja saamme 98% lohkoista, mutta ei 100%, tämä varmistaa, että kaikki pysyvät yksimielisyyteen , ja vaikka 98% ketju jatkuu pisimmällä painolla, ihmisten, jotka tekivät bip148-tyylisen nopean UASF: n, ei tarvitse päivittää ohjelmistojaan. “

“Kun otetaan huomioon, että U21: n skenaario 1021 on vain yhdistettävä siihen epätodennäköiseen pisteeseen, missä sitä tarvitaan?” Folkson kysyi.

“Kyllä, sillä on merkitystä vain, jos” vanhat “solmut käyttävät tätä koodia”, käyttäjä ghost43 vastasi.

Loppujen lopuksi molemmat PR: t yhdistettiin.

Yhteenvetona

BIP 8 (joka on BIP 9: n muunnos) näyttää olevan vakavin aktivointimekanismi tällä hetkellä. Mutta on kiistaa siitä, pitäisikö aktivoinnin olla vankka, vaikka se merkitsisi UASF: n riskiä, ​​kieltämällä kaivostyöläisten veto-oikeus; tee se turvallisesti todennäköisyydellä viivästyttää aktivointia, jos signalointi on riittämätöntä; tai aseta epätosi oletusarvoksi ja aktivoi tarvittaessa tosi. Ensimmäisen vaihtoehdon kannattajat katsovat, että kaivostyöläisten ei tarvitse pystyä häiritsemään yhteisöprosessia, kun taas toisen vaihtoehdon kannattajat pitävät UASF: n pudotusta tarpeettomana ja osoittavat perusteetonta asettamista, koska kaivostyöläiset ovat osoittaneet hyväksyvänsä Taprootin.

PR 1021 on BIP 8: n turvallisempi yleinen virhekorjaus, koska se estää ketjun jakautumisen joissakin tapauksissa, joissa yli 95 prosenttia, mutta alle 100 prosenttia kaikesta hajautusvoimasta tukee pehmeää haarukkaa.

Seuraava Taproot-aktivointikokous (tiistaina 16. helmikuuta klo 19.00 UTC) on asetettu keskittymään koodin tarkasteluun, jota seuraa toinen kokous parametrien keskustelemiseksi. Keskustelun jatkuessa Bitcoin lähestyy vuosien merkittävintä protokollapäivitystään.