Richh schreef op maandag 11 juni 2018 @ 14:36:
[...]
Een fee lost de spam inderdaad op. Dat is een 'voordeel' aan een kleine block size, daardoor forceer je een fee. Ben daar persoonlijk geen voorstander van overigens.
Maargoed, ik vraag het nog maar eens dan. Wou jij stellen dat er geen spam transacties zijn geplaatst tussen augustus en november?

Nee Bitcoin werd gewoon heel populair, de prijs ging steeds hoger. Iedereen had er ondertussen wel eens van gehoord. Steeds meer mensen stapte in en begonnen tx te maken naar exchanges en zo.
Van de 400 000 tx per dag die er over 2017 elke dag gemaakt zijn. Hoeveel daarvan denk je dat spam waren? 10%? 20%?
Mensen die dat doen die verliezen uiteindelijk hun bitcoin toch gewoon volledig aan de miners?
Bij een fee van 10 cent per tx kun je een dollar 10 keer uitgeven en dan heeft een miner hem.
Weet je wat in 2016 de kost prijs was voor een vol block? Ik kan dat voor je uitrekenen hoor.
Dat is inderdaad een groot probleem! Maar het vergroten van de blocksize lost dat ook niet op

LN is een oplossing maar misbruik blijft mogelijk. Ik weet eerlijk gezegd niet wat wel een goede oplossing is... Jij?
Het vergroten van blocksize is de enige oplossing. Core devs hebben geen kaas gegeten van economie. Behalve de allereerste core dev Gavin Andresen en Mike Hearn en Jef Garzik.
Gregory Maxwell bijvoorbeeld moet je eens zien wat die allemaal zegt. Ik vraag me af of jij het daar mee eens bent.
Personally, I'm pulling out the champaign that market behaviour is
indeed producing activity levels that can pay for security without
inflation, and also producing fee paying backlogs needed to stabilize
consensus progress as the subsidy declines.
I'd also personally prefer to pay lower fees-- current levels even
challenge my old comparison with wire transfer costs-- but we should
look most strongly at difficult to forge market signals rather than
just claims-- segwit usage gives us a pretty good indicator since most
users would get a 50-70% fee reduction without even considering the
second order effects from increased capacity.
As Jameson Lopp notes, more can be done for education though-- perhaps
that market signal isn't efficient yet. But we should get it there.
But even independently of segwit we can also look at other inefficient
transaction styles: uncompressed keys, unconfirmed chaining instead of
send many batching, fee overpayment, etc... and the message there is
similar.
I've also seen some evidence that a portion of the current high rate
congestion is contrived traffic. To the extent that it's true there
also should be some relief there soon as the funding for that runs
out, in addition to expected traffic patterns, difficulty changes,
etc.
Source:
https://lists.linuxfounda...2017-December/015455.html
Hij denkt dat de tx niet laten groein maar de fees wel een goed model is terwijl ik denk dat de fees zo laag mogelijk houden en de tx zelf gewoon laten groeien een model is dat duurzaam is voor de toekomst.
Omdat Satoshi nu juist probeerde een betaalsysteem te maken dat:
De kostprijs van deze tussenkomst
enverhoogt transactiekosten, beperkt de minimum praktische transactiegrootte
en de mogelijkheid om kleine losse transacties te plegen. Daarnaast is er
een bredere kost bij het verliezen van het maken van onomkeerbare betalingen en onomkeerbare diensten
Dit probleem oploste. Hoe kan Bitcoin nu dit probleem oplossen als het in de toekomst steeds duurder word omdat de miners betaald worden door hogere fees met dezelfde hoeveelheid tx.
Je schijnt de denken dat het opslaan van die blockchain zo een groot probleem is maar de chain kan
-gepruned worden.
- merkles trees kunnen gebruikt zie puntje 7 in de whitepaper.
Opslagruimte terugeisen
Zodra de laatste transactie in een munt begraven is onder genoeg blokken, kunnen de bestede
transacties weggegooid worden om schijfruimte te besparen. Om dit gemakkelijker te maken zonder
de hash van een blok te breken, worden transacties gehasht in een
Merkle Boom, met enkel
de wortel (root) opgenomen in de hash van het blok. Oude blokken kunnen dan compacter gemaakt worden door het kappen van de takken van de boom. De binnenste hashes hoeven niet opgeslagen worden. Een blok header zonder transacties zou rond de 80 bytes zijn. Als we veronderstellen dat blokken elke tien minuten gegenereerd worden, dan is 80 bytes * 6 * 24 * 365 = 4.2 MB per jaar. Met computersystemen die doorgaans 2
GB RAM hebben sinds 2008 en de Wet van Moore die een huidige
groei van 1.2 GB per jaar voorspelt, zou de opslag geen probleem mogen zijn zelfs als de blok headers
in het geheugen zouden moeten worden bewaard.
Kijk er is zeker iets te zeggen over exponentiële groei binnen het netwerk.
[
YouTube: https://youtu.be/hstM7aN_ozk?t=240]
De CPU validatie tijd die nodig is om elk blok te verifiëren binnen de tijd dat het volgend blok gemaakt word.
Dat zijn berekingen die op een gegeven moment te snel kunnen gaan groeien.
Maar dat gebeurd niet bij een blocksize van 1 MB of 2 MB of zelfs 500 MB. Dat zitten wel bij blocksizes van 1 GB.
En je vergeet ook dat miners momenteel iets van 90% kosten hebben aan stroom en 9,9% kosten aan nieuwe hardware de hele tijd. En nog geen 0.1% kosten aan harde schijf ruimte of bandbreedte.
En als er steeds meer transacties gemaakt worden dan hebben ze meer opbrengenste van fees en daar kunnen ze prima harde schijven van kopen of sneller internet.
Momenteel is de bandbreedte die binnen het Bitcoin netwerk gebruikt word super laag.
Kijk zelf.
https://statoshi.info/dashboard/db/bandwidth-usage
Ik had in 2008 als een seedbox van OVH met 1TB per maand en 100 mbit fullduplex en een harde schijf van 1 TB voor 12 euro per maand.
Het dogma dat het mis gaat met het netwerk omdat mensen geen non mining nodes kunnen draaien op hun rasberry pi is bullshit. Non mining nodes hebben geen schrijfrechten op de chain, alleen miners hebben die. Dus hoe kan een non mining node het netwerk beschermen tegen een aanval?
Alleen POW kan dat.
Zolang de miners gedecentraliseerd blijven. En hoe groter Bitcoin gebruik word, hoe meer het decentraal word.
Maar als je opzettelijk de groei tegenhoudt door die limiet zo laag te laten staan dan gaat het gewoon fout.
[
Voor 86% gewijzigd door
Kain_niaK op 11-06-2018 15:35
]