IMO:n mukaan on todennäköistä, että monille "mahdollisille roskapostittajille" mahdollinen hyöty suuren OP_RETURN tekemisestä oli pienempi kuin kustannukset (aika/vaiva) laajalle levinneen oletussuodattimen kiertämisestä (lähinnä siksi, että samanlainen asia saavutetaan pienemmillä kustannuksilla käyttämällä kirjoitustemppua), mistä johtuu tähän mennessä nähty suhteellisen vähän suuria OP_RETURNs, ja jyrkkä pudotus suodattimen kynnyksellä. Ensisijaisen peeringin ja/tai suoran lähettämisen ansiosta kustannukset pienenivät merkittävästi. Lisäksi kaiken keskustelun ja draaman (ja väistämättömän tulevan uutisoinnin suurten OP_RETURNs uusista käyttötavoista) myötä mahdollinen hyöty on kasvanut. Nyt kustannukset putoavat 0:aan (lukuun ottamatta sosiaalisen leimautumisen kustannuksia, jotka rajoittuvat hyvin pieneen ryhmään). On myös valtava arvo siinä, että transaktiosi pääsevät nopeasti useimpien louhijoiden ehdokaslohkoon, joten hyöty on kasvanut entisestään. Näistä syistä pidän todennäköisenä, että suurten OP_RETURNs esiintymistiheys kasvaa tulevina kuukausina, jos maksut pysyvät (naurettavan alhaisina) kuin ne ovat olleet viime kuukausina. En kuitenkaan usko, että tämä on ongelma. Huono OP_RETURN ei tapa bitcoinia, mikä on hyvä uutinen, koska jos se tappaisi bitcoinin, hyvin rahoitettu hyökkääjä voisi tehdä sen tänään louhimalla lohkon. Todennäköisin asia, jonka suuret OP_RETURNs syrjäyttävät, on joukko pienempiä OP_RETURNs lyövät paskakolikoita (riimuja) tai kirjoitustekstejä. Tämä on mahdollista vain siinä mittakaavassa, jossa se tapahtuu, koska maksut ovat historiallisesti alhaisia. Tämä on vähentyneen "laillisen" ketjutoiminnan jälkeen - imo tämä on paljon tärkeämpi "asia", joka ansaitsee huomiomme!

Sub 1 la/vB kesää opiskellaan tuleville sukupolville

Näen muutaman kommentin, jossa kysytään, mitä voidaan tehdä tämäntyyppiselle tietojen upottamiselle (joka on ollut olemassa jo pitkään). Tämä on hieman pitkä, mutta toivottavasti siitä on hyötyä viittauksena yleisempään kysymykseen siitä, voitko puuttua protokollatason "ongelmiin" louhijan/politiikan tasolla. Realistisesti katsottuna, ilman pehmeää haarukkaa on hyvin vähän tehtävissä teknisesti, ja silläkin olisi vakavia rajoituksia ja seurauksia (se on koko tämän karkean protokollasuunnittelun tarkoitus). Ilmeinen ensimmäinen reaktio on pyytää louhijoita lopettamaan tällaisten asioiden louhinta. On olemassa muutamia tapoja, mutta yksi olisi nostaa heidän -dustrelayfee-maksuaan Oletuksena se on 0,00003 BTC/kB (3 sat/vB), jolloin P2WSH:n pölyntuottoraja on 330 sat. Tässä tapahtumassa, jossa on 1859 tällaista lähtöä, kuluttomiin tuloksiin lukittu kokonaismäärä on 1859*330 = 613 470 satsia (736 dollaria @120 000 dollaria/BTC) Oletetaan, että lobbaat onnistuneesti suurimman osan (95 %) louhijoista 10-kertaiseksi tähän asetusarvoon, lähettäjän olisi valittava, maksaako hän 6,1 miljoonaa satelliittia (7 000 dollaria) vai lähettää sellaisenaan ja odottaa, kunnes pieni osa louhijoista (5 %) käyttää vanhaa oletusarvoa. He luultavasti tekisivät jälkimmäisen, koska se riittää keskimäärin 7 lohkon löytämiseen päivässä, ja mikä on kiire? Koska et ole onnistunut pysäyttämään tätä louhijatasolla, saatat nyt tuntea houkutusta lobata solmujuoksijoita muuttamaan oletusarvoaan ja/tai muuttamaan oletusarvoa core v31:ssä. Oletetaan, että onnistuit ja core v31 sisältää korkeamman oletusarvon. Lähettäjä voi vain mieluiten vertailla yrittääkseen tavoittaa louhijat protokollassa. Joten tuplaat ja huijaat ensisijaisen peeringin niin, että se ei ole riittävän luotettavaa. Lähettäjällä ei nyt ole muuta vaihtoehtoa kuin maksaa louhijalle OOB - jos he aikovat tehdä tämän, he voivat yhtä hyvin tehdä jokaisesta tuotoksesta 0 satsia. Tämä voisi itse asiassa olla molempien taloudellisesti hyödyllistä lähettäjälle ja louhijalle, koska sen sijaan, että satsit poltettaisiin maksuina, ne virtaisivat louhijalle / lähettäjä säästäisi ne. Ollakseni rehellinen, vaatisi vaivaa perustaa nämä suorat kiskot louhijoille, jotka ovat yksinomaan taloudellisesti motivoituneita, mutta tämä on kiinteä kustannus, ja minulla ei ole epäilystäkään siitä, että se tehtäisiin, ja sitten integroitaisiin API:n kautta keskitettyihin lyöntipalveluihin. Näin ollen ongelma olisi todennäköisesti pahempi kuin nykyinen tilanne.