Bitcoin Forum

Métallurgie
Inégalité de composition chimique entre les diverses parties d'un alliage métallique ; séparation de parties chimiquement hétérogènes durant la solidification d'un alliage.

Technique
Séparation en amas distincts d'un ensemble de corps différents préalablement mélangés.

Les utilisateurs seront poussés à changer leur logiciel Bitcoin Core pour aller vers la nouvelle version

Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the malleable parts of the transaction into the transaction witness, and segregating that witness so that changes to the witness does not affect calculation of the txid.

where an individual block required 25 seconds to validate, and maliciously designed transactions could take over 3 minutes.
Segwit resolves this by changing the calculation of the transaction hash for signatures so that each byte of a transaction only needs to be hashed at most twice.

When a hardware wallet signs a transaction, it can easily verify the total amount being spent, but can only safely determine the fee by having a full copy of all the input transactions being spent, and must hash each of those to ensure it is not being fed false data. Since individual transactions can be up to 1MB in size, this is not necessarily a cheap operation, even if the transaction being signed is itself quite small.
Segwit resolves this by explicitly hashing the input value. This means that a hardware wallet can simply be given the transaction hash, index, and value (and told what public key was used), and can safely sign the spending transaction, no matter how large or complicated the transaction being spent was.

they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (280) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker.
Segwit resolves this by using HASH160 only for payments direct to a single public key (where this sort of attack is useless), while using 256-bit SHA256 hashes for payments to a script hash.

additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.

Segwit improves the situation here by making signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size. This is expected to encourage users to favour the use of transactions that minimise impact on the UTXO set in order to minimise fees, and to encourage developers to design smart contracts and new features

To maintain the decentralised, trustless nature of Bitcoin, it is important to allow those who cannot afford to validate the entire blockchain to at least be able to cheaply validate as much of it as they can afford.
Segwit improves the situation here by allowing a future soft-fork to extend the witness structure to include commitment data, which will allow lightweight (SPV) clients to enforce consensus rules

At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.

Finding the most profitable set of transactions to include in a block given a single limit is an instance of the knapsack problem, which can be easily solved almost perfectly with a simple greedy algorithm. However adding the second constraint makes finding a good solution very hard in some cases, and this theoretical problem has been exploited in practice to force blocks to be mined at a size well below capacity.
It is not possible to solve this problem without either a hardfork, or substantially decreasing the block size. Since segwit can’t fix the problem, it settles on not making it worse: in particular, rather than introducing an independent limit for the segregated witness data, instead a single limit is applied to the weighted sum of the UTXO data and the witness data, allowing both to be limited simultaneously as a combined entity.

Several developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet, with initial testing being performed on a special testnet.

Segregated witness allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules.

The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit.

Segregated Witness, therefore, takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 2 MB).

Si j'ai bien compris, en langage imagé ... ça donnerait ceci :

réseau actuel = http://media.drive-fermier.fr/catalog/product/cache/46/image/1000x760/9df78eab33525d08d6e5fb8d27136e95/c/a/cageot_gourmand_-_l_gumes_de_saison_-_15_.jpg
Les transactions sont désorganisées dans le block.

réseau futur = http://perso.numericable.fr/serge.cormier/miniature/vitrines/epicerie_fruits_legumes.jpg
Le block contient une organisation propre structurelle permettant ... de gagner de la place (et donc d'en mettre plus avec la même taille finale).

Je me demande si ce type d'organisation fait du retard de block en fonction des frais (0-fee en fait) ... pour organiser des petites transactions ensembles (faible historiques) et des grosses transactions ensemble dans le prochain block (forte historique de mouvement).

Segregated witness soft fork

Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:

    Elimination of unwanted transaction malleability: Segregating the witness
      allows both existing and upgraded software to calculate the transaction
      identifier (txid) of transactions without referencing the witness, which can
      sometimes be changed by third-parties (such as miners) or by co-signers in a
      multisig spend. This solves all known cases of unwanted transaction
      malleability, which is a problem that makes programming Bitcoin wallet
      software more difficult and which seriously complicates the design of smart
      contracts for Bitcoin.

    Capacity increase: Segwit transactions contain new fields that are not
      part of the data currently used to calculate the size of a block, which
      allows a block containing segwit transactions to hold more data than allowed
      by the current maximum block size. Estimates based on the transactions
      currently found in blocks indicate that if all wallets switch to using
      segwit, the network will be able to support about 70% more transactions. The
      network will also be able to support more of the advanced-style payments
      (such as multisig) than it can support now because of the different weighting
      given to different parts of a transaction after segwit activates (see the
      following section for details).

    Weighting data based on how it affects node performance: Some parts of
      each Bitcoin block need to be stored by nodes in order to validate future
      blocks; other parts of a block can be immediately forgotten (pruned) or used
      only for helping other nodes sync their copy of the block chain.  One large
      part of the immediately prunable data are transaction signatures (witnesses),
      and segwit makes it possible to give a different "weight" to segregated
      witnesses to correspond with the lower demands they place on node resources.
      Specifically, each byte of a segregated witness is given a weight of 1, each
      other byte in a block is given a weight of 4, and the maximum allowed weight
      of a block is 4 million.  Weighting the data this way better aligns the most
      profitable strategy for creating blocks with the long-term costs of block
      validation.

    Signature covers value: A simple improvement in the way signatures are
      generated in segwit simplifies the design of secure signature generators
      (such as hardware wallets), reduces the amount of data the signature
      generator needs to download, and allows the signature generator to operate
      more quickly.  This is made possible by having the generator sign the amount
      of bitcoins they think they are spending, and by having full nodes refuse to
      accept those signatures unless the amount of bitcoins being spent is exactly
      the same as was signed.  For non-segwit transactions, wallets instead had to
      download the complete previous transactions being spent for every payment
      they made, which could be a slow operation on hardware wallets and in other
      situations where bandwidth or computation speed was constrained.

    Linear scaling of sighash operations: In 2015 a block was produced that
      required about 25 seconds to validate on modern hardware because of the way
      transaction signature hashes are performed.  Other similar blocks, or blocks
      that could take even longer to validate, can still be produced today.  The
      problem that caused this can't be fixed in a soft fork without unwanted
      side-effects, but transactions that opt-in to using segwit will now use a
      different signature method that doesn't suffer from this problem and doesn't
      have any unwanted side-effects.

    Increased security for multisig: Bitcoin addresses (both P2PKH addresses
      that start with a '1' and P2SH addresses that start with a '3') use a hash
      function known as RIPEMD-160.  For P2PKH addresses, this provides about 160
      bits of security---which is beyond what cryptographers believe can be broken
      today.  But because P2SH is more flexible, only about 80 bits of security is
      provided per address. Although 80 bits is very strong security, it is within
      the realm of possibility that it can be broken by a powerful adversary.
      Segwit allows advanced transactions to use the SHA256 hash function instead,
      which provides about 128 bits of security  (that is 281 trillion times as
      much security as 80 bits and is equivalent to the maximum bits of security
      believed to be provided by Bitcoin's choice of parameters for its Elliptic
      Curve Digital Security Algorithm [ECDSA].)

    More efficient almost-full-node security Satoshi Nakamoto's original
      Bitcoin paper describes a method for allowing newly-started full nodes to
      skip downloading and validating some data from historic blocks that are
      protected by large amounts of proof of work.  Unfortunately, Nakamoto's
      method can't guarantee that a newly-started node using this method will
      produce an accurate copy of Bitcoin's current ledger (called the UTXO set),
      making the node vulnerable to falling out of consensus with other nodes.
      Although the problems with Nakamoto's method can't be fixed in a soft fork,
      Segwit accomplishes something similar to his original proposal: it makes it
      possible for a node to optionally skip downloading some blockchain data
      (specifically, the segregated witnesses) while still ensuring that the node
      can build an accurate copy of the UTXO set for the block chain with the most
      proof of work.  Segwit enables this capability at the consensus layer, but
      note that Bitcoin Core does not provide an option to use this capability as
      of this 0.13.1 release.

    Script versioning: Segwit makes it easy for future soft forks to allow
      Bitcoin users to individually opt-in to almost any change in the Bitcoin
      Script language when those users receive new transactions.  Features
      currently being researched by Bitcoin Core contributors that may use this
      capability include support for Schnorr signatures, which can improve the
      privacy and efficiency of multisig transactions (or transactions with
      multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
      improve the privacy and efficiency of scripts with two or more conditions.
      Other Bitcoin community members are studying several other improvements
      that can be made using script versioning.

Et on peut suivre le support du SegWit chez les mineurs ici : https://coin.dance/blocks

88% des blocks sont déjà actuellement minés par un Bitcoin Core officiel.

Je pense que les mineurs attendent que les wallet soient tous compatibles : https://bitcoin.fr/segwit-encore-un-effort/

C'est, effectivement, très logique.

je ne comprends pas une chose : il y a 6 000 noeuds ou 54 000 ?

-50k (pas regardé si c'est au total ou seulement) n'acceptant pas les connexions entrantes et qui se connectent sur les 6000 autres nodes

Comme les autres, elle se connectent à des nodes qui elles acceptent les connexions entrante.

et également, ça créerait un deuxième bitcoin, avec un partage de la capitalisation boursière, non ?
si la fourche de unlimited arrive dès qu'elle le peut, c'est à dire à 50 %, il y aurait 2 monnaies qui pèseraient chacune 10 milliards d'euros, non ?
si je poursuis mon raisonnement, le temps que ça dure, les nouveaux investisseurs hésiteraient et ne sauraient pas dans laquelle investir, ce qui freinerait les achats.
en plus, et pendant quelles semaines, la capacité de calcul des 2 réseaux serait partagée en 2 parties égales, avec une difficulté qui resterait constante jusqu'aux prochains 2 016 blocks, d'où des confirmations qui s'éprennent toutes les 20 minutes au lieu de 10 minutes, renforçant ainsi la pagaille...
ça peut porter un coup sévère au bitcoin, ou pas ?

par ailleurs, même si unlimited est à 30 % et ne progresse plus vers 50 % mais reste à 30 %, il semble acquis que segwit ne pourrait atteindre 95 %, donc toute décision serait retardée pendant encore de longs mois. et donc les frais de transaction resteraient hauts et augmenteraient encore... il y a 2 ans, il y avait 4 000 euros de frais pour 100 000 transactions par jour, c'est à dire 4 centimes par transaction. il y avait 50 millions d'euros d'échangés par jour, soit une transaction moyenne de 500 euros et une commission de 0,008 %.
aujourd'hui, on est à 250 000 euros de frais pour 250 000 transactions par jour, c'est à dire 1 euro par transaction (en moyenne). il y a 250 millions d'euros échangés par jour, soit une transaction moyenne de 1 000 euros et une commission de 0,1 %...
on est venu au bitcoin car les frais étaient négligeables par rapport à une carte bancaire ou un western union, cet avantage est clairement en train de disparaitre, et avec des blocks complètement remplis comme actuellement, je ne vois pas les choses s'améliorer, il est largement possible que les frais augmentent encore beaucoup sur la base actuelle.

D accords donc en pratique le segwit passera bien ( bitcoin core si j ai bien suivis...) mais si l impasse persiste ds le systeme de vote actuel il va falloir envisager autre chose pour forcer tt le monde a etre d accords? Et ça sera quoi? ^^ et si j ai bien compris difficile d avoir une idee du timing?

 Autre precision par nod tu entends bien un noeuds? Toi ou moi avec la version segwit installée?

Les block de tailles non limité sont une hérésie financière.
Cela amènera les Fee a presque rien du tout et il toucheront moins de fee pour des blocs 20 fois plus gros.
Peut etre pas tous mais il y auras toujours un mineur en face qui s'en fout du prix minimum il mettre tous dans le block.

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).

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/

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.

This BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017

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 !

Gratuit ?  ???

Ma banque me facture des frais parce que la banque associée à Kraken est hors zone euro.
C'est quoi ta banque si ce n'est pas indiscret?

Il arrive à 60%.

So, for example, let’s say there’s 1000 transactions in the mempool, all at 1KB of data. Now let’s say in each of the transactions, 400 bytes is witness data and the other 600 bytes is transaction data. The 600 bytes for transaction data is now worth 2,400 units, while the witness data is now worth 400 units giving the whole transaction a weight of 2,800 units. All of these transactions together will only take up 2,800,000 of the 4,000,000 units, leaving room for more transactions.

Once the transaction is confirmed by the network, the not needed witness data will be pruned off the blockchain, to save storage space and decrease bandwidth use.

The addresses starting with 3 (nested Segwit in a P2SH type) are definitely backwards compatible: older (non-Segwit) wallet software can receive BTC from your P2SH addresses, and they can send to them too.

The addresses starting bc1 (bech32 P2WPKH type) are a new Segwit only type to make addresses easier to use. They essentially make addresess case-insensitive, e.g. BC1MYNEWBITCOINADDRESSISBECH32 is the exact same address as bc1mynewbitcoinaddressisbech32