Je sens qu'il faut que je lise pas mal de trucs parce que j'ai pas tout compris.
Je sais que les blocs actuels de 1MB posent problème vu le nombre de transactions à traiter, du coup on doit payer plus pour être sûr qu'une transaction passe rapidement (ou passe tout court). J'en ai fait l'expérience récemment en transférant plusieurs bitcoins avec un vieux client, j'avais mis les frais max mais ça a mis 3 jours car les frais max étaient encore trop bas...
Ce que je me dis c'est que si maintenant on exploite mieux les blocs avec plus de transactions par bloc, alors logiquement les frais doivent baisser, on est d'accord ?
Actuellement faire un virement en euros de mon compte FR vers Kraken c'est gratuit. L'inverse c'est 9 cents. Un transfert en Bitcoin me coûte plusieurs euros !
Topic: Segregated Witness, l'évolution prochaine du réseau Bitcoin. - page 2. (Read 16413 times)
SegWit entraîne automatiquement (une fois verrouillé évidemment) le lancement des canaux de paiement disponible par le Lightning Network (au-dessus de Bitcoin).
https://www.youtube.com/watch?v=pT9kJq_Ogrk
C'est ce que fait (déjà) Ethereum actuellement (et se fait donc déborder car il n'a pas assez de noeuds qui maintiennent le réseau en fonctionnement pour permettre cette sur-couche).
En principe, c'est le créateur de l'ICO qui devrait soutenir le fonctionnement Lightning sur Ethereum ... il n'en est rien et ça merde (en plus de coder des contrats avec les pieds et qu'ils soient acceptés par le réseau en plus).
Dans le cas de Bitcoin, 89% du réseau est maintenu par des gens extérieurs aux Exchanges (11% de mineurs en terme de poids nodale).
Le Lightining pourra donc obtenir les performances actuellement disponibles et testées sur le TestNet ...
Les exchanges attendent aussi le Lightining Network pour automatiser et décentraliser l'infrastructure des clients (et augmenter la visibilité des outils de trading et de visualisation des transactions).
Comment veux-tu pirater un compte client quand il est identifié par une clef privée ?
Tu peux pas.
En contre-partie, les Exchanges ouvriront et fermeront les canaux de paiement ... mais c'est déjà une tâches qu'ils font en interne au final (pour ceux qui relevé drastiquement leur sécurité interne).
https://www.youtube.com/watch?v=pT9kJq_Ogrk
C'est ce que fait (déjà) Ethereum actuellement (et se fait donc déborder car il n'a pas assez de noeuds qui maintiennent le réseau en fonctionnement pour permettre cette sur-couche).
En principe, c'est le créateur de l'ICO qui devrait soutenir le fonctionnement Lightning sur Ethereum ... il n'en est rien et ça merde (en plus de coder des contrats avec les pieds et qu'ils soient acceptés par le réseau en plus).
Dans le cas de Bitcoin, 89% du réseau est maintenu par des gens extérieurs aux Exchanges (11% de mineurs en terme de poids nodale).
Le Lightining pourra donc obtenir les performances actuellement disponibles et testées sur le TestNet ...
Les exchanges attendent aussi le Lightining Network pour automatiser et décentraliser l'infrastructure des clients (et augmenter la visibilité des outils de trading et de visualisation des transactions).
Comment veux-tu pirater un compte client quand il est identifié par une clef privée ?
Tu peux pas.
En contre-partie, les Exchanges ouvriront et fermeront les canaux de paiement ... mais c'est déjà une tâches qu'ils font en interne au final (pour ceux qui relevé drastiquement leur sécurité interne).
Je me demande l'effet que ça pourrait avoir sur le prix. D'un côté les transactions sont sensées mieux passer, mais du coup les mineurs seraient moins payés. Ou alors, les transactions se multipliant à nouveau, les mineurs seraient mieux payés, avec des fees plus basses pour les utilisateurs ?
ah, ça bouge un peu ...
tests en cours sur la ligne de commande -bip148 : https://github.com/bitcoin/bitcoin/pull/10532
cette commande de Bitcoin Core, si elle y est ajouté ... ne sera activable qu'entre le 1 aout et le 15 novembre.
dans cette période, cette commande pourrait afficher les noeuds bitcoin forçant celle-ci :
cette commande de Bitcoin Core, si elle y est ajouté ... ne sera activable qu'entre le 1 aout et le 15 novembre.
dans cette période, cette commande pourrait afficher les noeuds bitcoin forçant celle-ci :
Code:
Satoshi:0.14.2/!BIP148/
Ca veut dire que CSV non plus n'est pas activé sur BTC?
simplement que les pools ne signalant pas SegWit sont celles qui reçoivent le plus de puissance ... concentration = pas bon !
oui ? et ?
Merci pour ces informations Meuh6879, je viens d'ajouter la ligne uacomment au fichier de conf de mon noeud.
Mise en chantier chez les développeurs d'un BIP91 pour abaisser le basculement en segwit chez les mineurs à 80% (à déterminer) au lieu des 95%.
https://github.com/bitcoin/bitcoin/pull/10444
Le calendrier change pour la période ENFORCED (juin au lieu d'août) mais pas la date LOCK (novembre).
Ceci est écrit au "conditionnel" (à déterminer).
---
Ajout d'une prochaine option dans Bitcoin Core pour signaler la nécessité d'accepter SegWit au lieu de rester un utilisateur passif qui utilise la chaine majoritaire du réseau lorsqu'il allume son noeud Bitcoin Core.
https://github.com/bitcoin/bitcoin/pull/10442
C'est l'équivalent de ce que fait actuellement l'UASF (version modifiée 0.1-0.2-0.3 de Bitcoin Core).
https://github.com/bitcoin/bitcoin/pull/10444
Le calendrier change pour la période ENFORCED (juin au lieu d'août) mais pas la date LOCK (novembre).
Ceci est écrit au "conditionnel" (à déterminer).
Quote
This BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017
---
Ajout d'une prochaine option dans Bitcoin Core pour signaler la nécessité d'accepter SegWit au lieu de rester un utilisateur passif qui utilise la chaine majoritaire du réseau lorsqu'il allume son noeud Bitcoin Core.
https://github.com/bitcoin/bitcoin/pull/10442
C'est l'équivalent de ce que fait actuellement l'UASF (version modifiée 0.1-0.2-0.3 de Bitcoin Core).
Si vous aimez SegWit, il suffit de le dire lorsque vous lancez votre Bitcoin Core (officiel, il va de soi).
Vous apparaitrez dans la section UA-comment (et ici aussi = http://uasf.saltylemon.org/ ) :
Il suffit de faire ceci (source : http://www.uasf.co/ )
1) si vous savez où se trouve le fichier bitcoin.conf ... alors, rajoutez la ligne suivante dedans :
2) si vous ne savez pas ce que c'est que le fichier bitcoin.conf, modifiez simplement le raccourci qui lance votre Bitcoin Core comme cela :
Continuez d'utiliser les mises à jours officielles du Bitcoin Core de cette adresse : http://bitcoin.org/bin
Vous apparaitrez dans la section UA-comment (et ici aussi = http://uasf.saltylemon.org/ ) :
Il suffit de faire ceci (source : http://www.uasf.co/ )
1) si vous savez où se trouve le fichier bitcoin.conf ... alors, rajoutez la ligne suivante dedans :
Code:
uacomment=UASF-SegWit-BIP148
2) si vous ne savez pas ce que c'est que le fichier bitcoin.conf, modifiez simplement le raccourci qui lance votre Bitcoin Core comme cela :
Continuez d'utiliser les mises à jours officielles du Bitcoin Core de cette adresse : http://bitcoin.org/bin
le pire, dans tout cela, c'est qu'il suffit que SegWit soit actif pour déjà avoir plus de latitude dans les blocks de 1Mb actuels.
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
ces mineurs cachent définitivement quelque chose ... pour ne pas vouloir du SegWit et proposer le système BU puis le Segwit2Mb comme pièges successifs de communication.
Quote
The current proposal for soft fork segregated witness (segwit) replaces the block size limit with a new block cost limit, counting each byte of witness data as 1 unit of cost and UTXO transaction data as 4 units; as a result, the maximum size of a block becomes just under 4 MB.
However, blocks are not expected to consist entirely of witness data, so blocks near 4 MB in size would be unlikely.
According to some calculations performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6 MB and a block filled with 2-of-2 multisignature transactions would be about 2.0 MB. It is further likely that future scaling improvements, such as Lightning, may slightly improve the ratio such that filled blocks become larger than 2 MB.
However, blocks are not expected to consist entirely of witness data, so blocks near 4 MB in size would be unlikely.
According to some calculations performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6 MB and a block filled with 2-of-2 multisignature transactions would be about 2.0 MB. It is further likely that future scaling improvements, such as Lightning, may slightly improve the ratio such that filled blocks become larger than 2 MB.
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
ces mineurs cachent définitivement quelque chose ... pour ne pas vouloir du SegWit et proposer le système BU puis le Segwit2Mb comme pièges successifs de communication.
J'en profite pour poser une question sur le XBU :
Les partisans de bitcoin unlimited ont donc créé leur propre blockchain avec des blocs de 2mb ?
https://coinmarketcap.com/currencies/bitcoin-unlimited/
Les partisans de bitcoin unlimited ont donc créé leur propre blockchain avec des blocs de 2mb ?
https://coinmarketcap.com/currencies/bitcoin-unlimited/
RTFM : https://www.bitfinex.com/cst_token_terms
Merci pour ces informations.
Le sujet est complexe.
il suffit qu'une majorité du réseau et des mineurs aient accepté le Segwit2Mb ... pour qu'on se retrouve, comme par hasard, à attendre le segwit de-nouveau sur une longue période mais avec des block de 2Mb.
Donc retour à la case départ mais avec des blocs de plus de 1mb?
ce qui donne tout la latitude aux BU et aux Classic/XT pour reprendre de l'ampleur ... car le réseau acceptera les blocks plus gros que 1Mb ... virant d'autant tous les clients légitimes voulant le SegWit, étant prêt ... et refusant les blocks de plus de 1Mb qui ne contiennent pas les instructions SegWit.
cette dernière phrase est cruciale : activer des blocks plus gros AVANT l'activation des instructions SegWit.
Beau piège comme je le disais (c'est pour ça que j'ai décrit le calendrier plus que l'object en question).
C'est ça qui entrainerait donc le fork ? on parle de hard fork ?
J'en profite pour poser une question sur le XBU :
Les partisans de bitcoin unlimited ont donc créé leur propre blockchain avec des blocs de 2mb ?
https://coinmarketcap.com/currencies/bitcoin-unlimited/
Le sujet est complexe.
il suffit qu'une majorité du réseau et des mineurs aient accepté le Segwit2Mb ... pour qu'on se retrouve, comme par hasard, à attendre le segwit de-nouveau sur une longue période mais avec des block de 2Mb.
Donc retour à la case départ mais avec des blocs de plus de 1mb?
ce qui donne tout la latitude aux BU et aux Classic/XT pour reprendre de l'ampleur ... car le réseau acceptera les blocks plus gros que 1Mb ... virant d'autant tous les clients légitimes voulant le SegWit, étant prêt ... et refusant les blocks de plus de 1Mb qui ne contiennent pas les instructions SegWit.
cette dernière phrase est cruciale : activer des blocks plus gros AVANT l'activation des instructions SegWit.
Beau piège comme je le disais (c'est pour ça que j'ai décrit le calendrier plus que l'object en question).
C'est ça qui entrainerait donc le fork ? on parle de hard fork ?
J'en profite pour poser une question sur le XBU :
Les partisans de bitcoin unlimited ont donc créé leur propre blockchain avec des blocs de 2mb ?
https://coinmarketcap.com/currencies/bitcoin-unlimited/
disons qu'ils essayent de la jouer en "on va forcer le segwit d'abord ... puis on passera le 2Mb en même temps" ... sauf que le réseau n'acceptera pas ça (et ne sera pas aussi rapide à se transformer).
donc, fork oui.
surtout que le 2Mb est actif avant le SegWit dans cette discussion.
il suffit qu'une majorité du réseau et des mineurs aient accepté le Segwit2Mb ... pour qu'on se retrouve, comme par hasard, à attendre le segwit de-nouveau sur une longue période mais avec des block de 2Mb.
ce qui donne tout la latitude aux BU et aux Classic/XT pour reprendre de l'ampleur ... car le réseau acceptera les blocks plus gros que 1Mb ... virant d'autant tous les clients légitimes voulant le SegWit, étant prêt ... et refusant les blocks de plus de 1Mb qui ne contiennent pas les instructions SegWit.
cette dernière phrase est cruciale : activer des blocks plus gros AVANT l'activation des instructions SegWit.
Beau piège comme je le disais (c'est pour ça que j'ai décrit le calendrier plus que l'object en question).
donc, fork oui.
surtout que le 2Mb est actif avant le SegWit dans cette discussion.
il suffit qu'une majorité du réseau et des mineurs aient accepté le Segwit2Mb ... pour qu'on se retrouve, comme par hasard, à attendre le segwit de-nouveau sur une longue période mais avec des block de 2Mb.
ce qui donne tout la latitude aux BU et aux Classic/XT pour reprendre de l'ampleur ... car le réseau acceptera les blocks plus gros que 1Mb ... virant d'autant tous les clients légitimes voulant le SegWit, étant prêt ... et refusant les blocks de plus de 1Mb qui ne contiennent pas les instructions SegWit.
cette dernière phrase est cruciale : activer des blocks plus gros AVANT l'activation des instructions SegWit.
Beau piège comme je le disais (c'est pour ça que j'ai décrit le calendrier plus que l'object en question).
du coup passer par un hard fork ?
Très bon piège : https://bitcointalksearch.org/topic/the-barry-silbert-segwit2x-agreement-with-80-miner-support-1928093
En clair, ils veulent :
- une augmentation à 2Mb
- puis le Segwit
En relisant le BIP148 (SegWit officiel) :
- période de transition (SegWit peut revenir en arrière) : de aout à novembre
- période de verrouillage (SegWit sera fixe et utilisable) : après novembre
Période pour ce qu'ils veulent eux, le 2Mb :
- septembre
C'est un beau piège mais assez facile à débusquer.
Très dangereux surtout.
En clair, ils veulent :
- une augmentation à 2Mb
- puis le Segwit
En relisant le BIP148 (SegWit officiel) :
- période de transition (SegWit peut revenir en arrière) : de aout à novembre
- période de verrouillage (SegWit sera fixe et utilisable) : après novembre
Période pour ce qu'ils veulent eux, le 2Mb :
- septembre
C'est un beau piège mais assez facile à débusquer.
Très dangereux surtout.
Ça avance on dirait bien.
- https://cointelegraph.com/news/bitcoin-miners-agree-in-ny-on-segwit-activation-before-september-sources
- https://cointelegraph.com/news/bitcoin-miners-agree-in-ny-on-segwit-activation-before-september-sources
Jump to: