My quick guess is that you're not taking into account how Graphene treats canonical signatures.
For reference, check xeroc's excellent post on transaction signing: https://steemit.com/steem/@xeroc/steem-transaction-signing-in-a-nutshell
Here's an extract:
Now, we are going to implement a loop that is crucial because the back-end only accepts canonical signatures and we have no way of knowing if the signature that is going to be produced will be canonical. That said we will derive a deterministic k parameter for the ECDSA signing and while generating this parameter will will add our loop counter to the digest before hashing. This results in a new deterministic k each round which will result in either a canonical or non-canonical signature.
I know a lot more about tendermint than I do graphene.
This could be the issue but I don't know, because well, if that is the case it doesn't seem real sensible. Thank you for your suggestion we will surely give this a try.
I reckon it's 99% certain this is the cause of your issue.
You may reckon right.
What do you think of the idea that this baroque chapter in the process should be simplified?
Hey rainman thanks for this explanation. Ill grab xeroc to bring further into this discussion. I hope this is the reason...cause when same input somehow = different output every time...it concerns me. Looks like i need to do some reading. Please stay in this discussion as u are already proving to be highly valuable.
This is at the core of the reasons why faddat and baabeetaa could not build the beyondbitcoin.io site ...and also stopped them from making it easy to crosspost to steem from their social "media hub" blockchain.
I believe signatures will be different every time and that is expected, since we're dealing with non-deterministic signatures here.
Anyways, xeroc'x post over there is how I managed to solve this in graphenej. The relevant part of the code is in here: https://github.com/kenCode-de/graphenej/blob/master/graphenej/src/main/java/de/bitsharesmunich/graphenej/Transaction.java#L142
Should it be simpler?
And thanks.
Steem community,
Can anyone really read that doc and not get the heebie jeebies about widening the attack surface?
I'm sorry, but it truly seems baroque. What happened to simple is beautiful?
And this is my honest advice: stop doing things that are done better, yourself. grpc is better than this for you and for developers. Capn'proto would also work.
You may proceed with the ritualistic throwing of eggs.
You are also encouraged to test the crap out of our chains security in the same fashion. Maybe, somehow we can all make this work. And it would be neat, because there's a lot we can offer each other, and this is me all "whoa, alright, cool, but totally that's not... What you might ever expect..."
If you really need sonething canonical you can try the rfc-compliant k and if the sig fail to be canonical .. you can increment k by one until you sig is canonical. Easy as that.
@xeroc
Your word carries a lot of weight with me, so please put it to me squarely:
Do you think this poses a threat to security?
How about usability?
Isn't it something that can be simplified a great deal?
If I'm off-base here, tell me so.
Just give up the FUDing already, we've explained why you had this issue. There is no security issue here, in fact it's a non issue that you're attempting to make a big deal out of.
If you weren't trying to FUD you would've just asked someone like xeroc who knows how this works and he would've explained it in 1 minute.
In fact, these more strict requirements make the system more secure.
You can realize that when you think about it from the information theoretical point of view. The requirement for
randseach being of length 32 means that the signature has to have a length of64(+1 for the pubkey recovery parameter). This requirement makes it impossible to leak information of the private key into the signature, no matter what you do.As for not being deterministic, there actually is no requirement for it whatsoever. All that RFC6979 results in is a random k which is needed to prevent an easy derivation of
kfrom two signatures (if the same k is used twice). This can be done by using RFC6979, or just some random timestamp. Being able to deterministically derivekhas no other impact than making sure thatkisn't reused. And for that reason, graphene (as well as most clients) implement RFC6979 and then permute thekif necessary.@svk
Attitudes like that are a threat to security here. Hell, it's why I stopped using the site. Why is there this extreme anti-progress undercurrent around here?
Hey xeroc, regarding to Piston, is this still available?
There is a 'Lost connection to node' error message.
Dear @rainman
I can see you voted for witness arhag who doesn't have a working witness anymore since a long time.. I am new, dedicated and hoping to achieve dreams. Your vote can really really help me. I hope you would consider it.. https://steemit.com/witness-category/@rival/rival-week-2-steem-witness-update-thank-you-daretoask