Nostr Web Client

Réflexion au sujet de BTC/BCH, suite au visionnage de cette vidéo : https://youtu.be/7MJybRBlqiM

S'il s'avère vraiment que le stockage devrait prochainement faire un bond important en termes de performances/coûts, la faible décentralisation amenée par les gros blocs serait moins vraie.

Qu'en pensez vous ?

Pas que BCH devienne bitcoin, mais peut-être qu'une nouvelle réflexion pourra s'ouvrir sur Bitcoin pour donner plus de flexibilité à leur taille de blocs ?

Utile, pas utile ?

Dangereux, pas dangereux ?

Reply to this note

Please Login to reply.

Discussion

JohnOnchain 2y ago

Ce n'est pas tant le stockage que le compute et la bande passante nécessaire. Il y a certes des gains mais par augmentation, il faut s'entendre de quoi on parle.

Si il s'agit de settle tout on chain, alors le layer 1 pour "on board le monde entier" ne sera pas suffisant avec de simple PC.

weedcoder 2y ago

cette question est un marronier.

la courbe de l'évolution compute/data de bitcoin doit être en dessous de la courbe de l'évolution compute/data de l'informatique grand public. c'est tout :)

weedcoder 2y ago

pour onboard tout le monde, nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk, le plus conservateur, a dit : bloc de 128 Mo + LN.

CryptoSou 2y ago

Et là comme dit nostr:npub1r34nhc6nqswancymk452f2frgn3ypvu77h4njr67n6ppyuls4ehs44gv0h c'est la bande passante qui pose problème (si on postule que le stockage n'en est plus un).

Ok je vois.

Et effectivement, la bande passante nécessaire me paraît trop élevée pour conserver une bonne décentralisation.

Bon...

Luke Dashjr 2y ago

???

Luke Dashjr 2y ago

We need smaller blocks

RealJohnDoe 2y ago

https://youtu.be/koRQtFTHfTI -Kong

#Ordinals #nfts #bcr20 etc have to go. #Bitcoin #fees are for Bitcoin #transactions. The expenses of running #nodes and other support services for Bitcoin, are for Bitcoin.

Ordinals, nfts, BRC20 etc are #theft. They artificially inflate transaction fees. Creating Bitcoin inflation and Bitcoin value debasementIt. It recreates the Fiat cantilian effect for those closest to the money printer.

It's fraud and larceny, and ripe for a massive class action lawsuit. Ripe for SEC, CFTC, FTC and FBI prosecution.

Bitcoin's not a toy. They should have learned that during segwit and the block size wars. Millions of individuals and entire countries have their hopes and dreams wrapped up in the #purity and #integrity of the Bitcoin #protocol.

They are playing with King Kong, and they're gonna get squished..🧡👑

#JustSaying

CryptoSou 2y ago

I disagree with this vision, but nvm, the market will decide.

Ordinals, nfts, BRC-20 are not efficient on L1 anyway, so not a real threat. Only a little episode of Bitcoin life.

RealJohnDoe 2y ago

https://youtu.be/nh1FjMDKMNw

"did you not hear me?" 💀🤭

CryptoSou 2y ago

What's the interest...

Decentralization is decent and current block size is not a big barrier.

Luke Dashjr 2y ago

Spoken like someone who doesn't know what he's talking about

CryptoSou 2y ago

Or someone asking.

But you can be like you are...

Luke Dashjr 2y ago

But you didn't ask, you stated "decentralization is decent", which isn't remotely true

CryptoSou 2y ago

"I didn't ask..."

nostr:nevent1qqsxvnezr7ys0vnuh24thh2pln9rg6a5vv470lw42rfcmxm3yeuvc9qppamhxue69uhkummnw3ezumt0d5pzq6vq2ah5cfshww56qvpnm8d7myfmsp45kzlru8k9a8xnemmahsf9qvzqqqqqqy7v6r0z

Yes, I asked, it even was nothing else than a question I had.

Yes I like to question the protocol, nothing is done forever, even Bitcoin.

And if we disagree about this, so we do, it's fine :⁠-⁠)

Bitcoin doesn't care about how you and me are using it, or why, and that's the only important thing for me.

Unhosted Marcellus 2y ago

What sections you think need the chop chop, the virtual block, segwit data or both?

Luke Dashjr 2y ago

There are no sections...🤨

Unhosted Marcellus 2y ago

I'm afraid I'm not familiar with the precise wording.

What I meant to ask is if you think the block size should be reduced maintaining the same proportion of segwit to virtual block data (e.g. 0.5MB virtual, 1.5MB segwit) or just clip the segwit data (e.g. 1MB virtual, 1MB segwit).

Luke Dashjr 2y ago

Ideally something like 600kWU limit with non-segwit signatures given the same discount.

Unhosted Marcellus 2y ago

Sounds rough, if I'm not mistaken that'd be just 150kb of virtual data per block 💀 How do you get to that number?

Luke Dashjr 2y ago

There's no such thing as virtual data...

Blocks would be about 300k

Unhosted Marcellus 2y ago

Well, there is segwit data that weights 1WU, and non-segwit data that weights 4WU, no? 🤔

For 600kWU max block sizes would range from 150kb (block with only legacy txs) to 600kb (almost no txs and huge taproot script/monke pic)

Luke Dashjr 2y ago

Again, I would give the same 1 WU/B discount to non-segwit ("legacy"😮‍💨) signatures.

Blocking spam is a different issue, to be resolved in a different way (maybe).

Unhosted Marcellus 2y ago

Aight, now I gotchu. Thanks for the patience 😬

Léo 2y ago

Malheureusement ce n’est pas juste une question de stockage, par exemple en ce moment la taille du set d’UTXO explose alors qu’il doit être aussi petit que possible pour pouvoir être maintenu dans la ram

Également de plus gros bloc veut dire plus de TXs donc plus de ressource au niveau du processeur pour valider un bloc.

En bref toute augmentation aura un effet assez conséquent sur les ressources nécessaires pour exécuter un noeud.

CryptoSou 2y ago

Il y a des moyens de pruner ça, ou d'adresser le besoin différemment ?

Si non, effectivement vrai souci.

Concernant les ressources de processeur, je n'avais pas encore entendu que c'était un souci sauf pour la première sync.

Léo 2y ago

Pour les UTXOs il faut regarder du coté d’utreexo qui permet a un noeud de ne pas avoir besoins de les stocker mais les transactions devront être plus grosse et potentielment augmenter la taille de bloc.

C’est le serpent qui se mort la queue.