je constate une différence dans l’api BMA le hash des transactions n’y est plus :
1.6.25 :
https://duniter.fabwice.com/blockchain/block/52
1.7.7
https://g1.bertrandbenjamin.com/blockchain/block/52
et moi qui me demandais ce qui ne va pas dans mon code! on dirait que quelqu’un cherche à nous faire implémenter nos fonctions plutôt que donner le résultat… damn you @cgeek
1.6.29 :
"transactions": [
{
"version": 10,
"currency": "g1",
"locktime": 0,
-- "hash": "9B67B25DD17D6E3A3E7D3E5F830F7CB481DA10FC11BD8A955CF74A572DE60825",
"blockstamp": "50-00001DAA4559FEDB8320D1040B0F22B631459F36F237A0D9BC1EB923C12A12E7",
"blockstampTime": 1488990016,
"issuers": [
"2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ"
],
"inputs": [
"1000:0:D:2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ:1"
],
"outputs": [
"1:0:SIG(Com8rJukCozHZyFao6AheSsfDQdPApxQRnz7QYFf64mm)",
"999:0:SIG(2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ)"
],
"unlocks": [
"0:SIG(0)"
],
"signatures": [
"fAH5Gor+8MtFzQZ++JaJO6U8JJ6+rkqKtPrRr/iufh3MYkoDGxmjzj6jCADQL+hkWBt8y8QzlgRkz0ixBcKHBw=="
],
"comment": "TEST"
}
],
1.7.9 :
"transactions": [
{
"version": 10,
"currency": "g1",
"locktime": 0,
"blockstamp": "50-00001DAA4559FEDB8320D1040B0F22B631459F36F237A0D9BC1EB923C12A12E7",
"blockstampTime": 1488990016,
"issuers": [
"2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ"
],
"inputs": [
"1000:0:D:2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ:1"
],
"outputs": [
"1:0:SIG(Com8rJukCozHZyFao6AheSsfDQdPApxQRnz7QYFf64mm)",
"999:0:SIG(2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ)"
],
"unlocks": [
"0:SIG(0)"
],
"signatures": [
"fAH5Gor+8MtFzQZ++JaJO6U8JJ6+rkqKtPrRr/iufh3MYkoDGxmjzj6jCADQL+hkWBt8y8QzlgRkz0ixBcKHBw=="
],
"comment": "TEST",
++ "block_number": 0,
++ "time": 0
}
],
Thanks to our international investigation team, the mystery is solved : it was on purpose!
What ? Why is it on purpose ? I mean, all the python parsers are waiting for this field to be present. Why would it be removed ?
Would you open a ticket?
No need :
if you know how to post a tx, you dont need to hash it, for my part I put it in the getter :
/**
@return the hash
/
public String getThash() {
if(thash == null )
thash = Crypto.hash(toDUPdoc(false));
return thash;
}
where false is “signed”…
consider it an opportunity for you to overcome new challenges … 
Why ? it must be the expected behaviour since this field is redundant.
The absolute answer is in the file TransactionDTO
essentially, you get the text version of the transaction DOCUMENT, the same part you use to sign .
then you hash it just like you would sign
sign( txDoc , issuers )
hash( txDoc )
Its actually simpler !
That’s not my point, I’m know that this field is redundant and that you can build the hash “on the fly”.
For instance, it will break Sakia if too much nodes are starting to run 1.7 version : https://git.duniter.org/clients/python/sakia/blob/master/src/sakia/services/transactions.py#L87 ,
I hope that Cesium does not suffer the same problem.
I’m just a bit annoyed to see BMA broken again by a Duniter upgrade 
I know that @cgeek tries to avoid it. I also think that this change is justified. But in the future, we will have to set API as “obsolete” for some time before breaking it, to give time to clients and services developers and avoid breaking running services.
Well, for now, we shouldnt put too much effort on BMA. But we have to find a way in GraphQL project to define some fields as “obsolete” when we plan to remove/modify them.
Ceci n’est pas voulu, c’est un bug. Je viens de le tracer avec le ticket#1328 et vous invite à prendre ce réflexe.
I do not try: I guarantee this by writing an automated test. Unluckily even with 700+ automated tests and static typing, no one was covering this specific case.
This will be fixed when resolving ticket#1328.
Erf, excuse nous alors 
a l’avenir, tout changement de BMA devra donc être signalé comme un bug. C’est cohérent avec le caractère obsolète de BMA.
Oui exactement.