Can Armory multisig lockbox have more than one funding address?

[idoB]

Thanks for the explanation.

In retrospect (always 20-20), I was sniffing close to  the section of the code that turned out to be the issue, in the file /ui/MultiSigDialog.py, which is why I asked you for a confirmation of the file in a previous post.

What made me look closer, however, wasn't any coding expertise unfortunately, (I was having a hard time just getting my head around what I was reading), but these two lines that hinted on fragile code  :

Code:

      # Not sure if we really need this...

https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2983

and

Code:

      # This is complex, for sure. 
      #    The outermost loop goes over all inputs and outputs
      #    Then goes over all N public keys 
 

https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2991

But eventually I got derailed by what you commented as unrelated.

I would'nt have guessed that compressing keys changes their order (which is critical for signing a lockbox spending transaction).

[goatpig]

With the encoding used (not sure what it's called anymore), uncompressed keys start with 0x04. Compressing the key means to only carry the X value (first 32) bytes, with an extra leading byte to signify parity and compression (in this case, 0x02 and 0x03). This works because since Y is squared, both positive and negative values of X fit a solution.

While the X value remains the same, parity shenanigans can change the canonical order of the keys, since it is the header byte.