Ah ben nos messages se sont croisés car j'avais trouvé le full diclosure aussi et mis à jour mon post ;p
Si tu as les connaissances nécessaires en code je suis preneur d'une petite explication de comment ils peuvent augmenter le supply avec un tel bug. Autant bloquer des noeuds je comprends mais augmenter le supply ca doit être un poil plus compliquer.
Je vais essayer de répondre, au moins d'éclaircir certains aspects. Voici un truc à savoir, dans la construction des transactions bitcoin, pour comprendre ce bug.
Quand vous recevez des bitcoins, le wallet dont vous en recevez va prendre un output qui le concerne, le mettre en input, et créer la transaction avec votre addresse en output.
Quand vous envoyez des bitcoins, en fait vous "dépensez" un output qui à été fait à une adresse publique, dont vous avez la clé privée, qui correspond. Donc vous mettez cet output en tant qu'input, et en output, la destination de la transaction...
(Source :
https://bitcoincore.org/en/2018/09/20/notice/ )
In Bitcoin Core 0.15, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists.
Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch). However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Bitcoin as they would be then able to claim the value being spent twice.
Dans Bitcoin Core 0.15, dans le cadre d'une large refonte pour simplifier le suivi des transactions non dépensées, et donc corriger un vecteur d'attaque qui épuisait certaines ressources, le test a été changé subtilement. Au lieu de tester que l'output qu'on marque comme "dépensé" était dans le passé "non-dépense", on teste seulement que l'output existe dans la blockchain.
En conséquence, dans Bitcoin Core 0.15.X, 0.16.0, 0.16.1 et 0.16.2, une tentative de double-dépense d'un output de transaction dans un block où l'output a été crée, une erreur de test (assert) va se produire.
En revanche, si l'output qui est "double-dépensé" a été crée dans un block précédent, de la façon dont le test est actuellement fait, l'output sera considéré comme existant, mais "dépensé" et donc le test (assert) va réussir sans erreur car l'output existe. Cela permet à un mineur d'augmenter la quantité de bitcoins car ils peuvent récupérer la valeur qui a été double dépensé.
En gros, ils ont changés une manière de faire des tests dans une version récente, pour que Bitcoin Core gagne en performances sur certaines choses.
Cette mise à jour permet à un mineur(!) malicieux, de tricher. (Un mineur qui a 20 ASIC ne peut rien faire tout seul dans ce cadre là hein ..)
Nous étions donc tous concernés par cette faille, seulement quelques individus pouvaient réellement en tirer profit. Ça ne concerne pas les mineurs qui minent dans des pools.
C'est plutôt ceux qui construisent le header du block dont on calcule la preuve de travail, vraiment, qui peuvent en profiter.
Donc quelques personnes dans le monde, ceux qui sont à la têtes des pools...
Et si jamais ils le font, que se passera t'il par la suite pour leur opération ? Si une pool triche, et que ça s'apprend ? Ça s'apprendra, car tout est transparent.
Vaut mieux peut être s’abstenir, hein ?
Bitcoin en a vu d'autres. Style, un block qui a crée ... 93 milliards de bitcoins
The "value out" in this block #74638 is quite strange:
{
{
"hash" : "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 2,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39",
"n" : 0
},
"scriptSig" : "0xA87C02384E1F184B79C6ACF070BEA45D5B6A4739DBFF776A5D8CE11B23532DD05A20029387F6E4E77360692BB624EEC1664A21A42AA8FC16AEB9BD807A4698D0CA8CDB0021024530 0x965D33950A28B84C9C19AB64BAE9410875C537F0EB29D1D21A60DA7BAD2706FBADA7DF5E84F645063715B7D0472ABB9EBFDE5CE7D9A74C7F207929EDAE975D6B04"
}
],
"out" : [
{
"value" : 92233720368.54277039,
"scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value" : 92233720368.54277039,
"scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG"
}
]
}
],
"mrkl_tree" : [
"012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca",
"1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
"618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e"
]
}
92233720368.54277039 BTC? Is that UINT64_MAX, I wonder?
Avec chaque bug découvert et résolu, bitcoin n'en devient que plus robuste et résilient.
