stream permission transfer not possible

Question

Hi,

I want to transfer stream.all permissions from one multisig-address to another multisig-address but at the end I get the error: "64: Inputs don't belong to valid admin"

In detail:
I have two nodes (node 1, node 2) with a mutual multisig-addr. "4A" and two additional nodes (node 3, node 4) with a mutual multisig-addr. "4B". Both addresses have send and receive permissions. Now I create a stream "stream01" and grant 4A stream01.all.

To transfer stream.all from 4A to 4B I do:

createrawsendfrom 4A {"4B":{"permissions":{"for":"stream01","type":"all"}},"4A":{"permissions":{"for":"stream01","type":"all","startblock":0,"endblock":0}}}

This gives me a hex-blob. On node 1 I do signrawtransaction with the hex-blob
and get a new hex-blob to do the same on node 2. I get "complete":true and the final hex-blob.

Now I do:

sendrawtransaction final hex-blob

this works.

 

Now what doesn't work:

When I try to reverse the transaction like this:

createrawsendfrom 4B {"4A":{"permissions":{"for":"stream01","type":"all"}},"4B":{"permissions":{"for":"stream01","type":"all","startblock":0,"endblock":0}}}

I get the hex-blob, do the signing and then try to send.

This time I get the "64: Inputs don't belong to valid admin"-error.

 

Is there something I missed? Is this intended? How can I transfer the permissions for a stream from multisig to multisig?

 

Thanks for your answer!

-zolar-

 

edit: I'm working with Multichain 1.0.5

Answer 1

I'm not completely sure yet, but I found out two things:

1. vin is completely irrelevant for stream-permission-transactions. You can put there "anything" you like
2. the order in vout is highly relevant for this transaction to succeed

So my solution for this problem is to do

createrawtransaction ["something from 'listunspent 0 9000 ["4B"]'"] {"4A":{"permissions":{"for":"stream01","type":"all"}}

--> gives you a hex-blob

 

then:

appendrawtransaction hex-blob ["something else from 'listunspent 0 9000 ["4B"]'"] {"4B":{"permissions":{"for":"stream01","type":"all","startblock":0,"endblock":0}}}

 

The hex-blob from appendrawtransaction can be sent without errors after all signatures are applied.

Worked for me so far...

 

It is important to build the transaction step-by-step to get the right order in vout in the final transaction.

 

-zolar-

 

 

Answer 2

You should be able to do this using createrawsendfrom and you don't need to add the second permission going back to the original address. This worked fine (not using multisig addresses):

createrawsendfrom <from-address> '{"<to-address>":{"permissions":{"for":"stream01","type":"all"}}}' '[]' sign

Comments

I want to revoke the permission from the original address when it is granted to the next address in the same transaction.
Just granting permission to another address works fine.

---

OK, well, you may want to use smart filters (just available in MultiChain 2.0 alpha 5) for this. You can check that any time an address is given admin permission for a stream, the other address has the admin permission removed. Here's an example of a raw transaction that effectively transfers admin permissions from one address (1WZuzuLEcY78pdsjvVifNH3frXcHvFXpsjusPq) to another (17zYQ4uF7FPQWyjxjMwWnffwuTGqRiNbUqWDMy):

createrawsendfrom 1WZuzuLEcY78pdsjvVifNH3frXcHvFXpsjusPq '{"17zYQ4uF7FPQWyjxjMwWnffwuTGqRiNbUqWDMy":{"permissions":{"for":"stream1","type":"admin"}},"1WZuzuLEcY78pdsjvVifNH3frXcHvFXpsjusPq":{"permissions":{"for":"stream1","type":"admin","startblock":0,"endblock":0}}}' '[]' send

---

I haven't touched smart filters yet but I will have a look into them!
Thank you for the example. Actually I have tried it exactly like this and it worked... sometimes.
In some (more complex) cases, e.g. if you additionally transfer write-permissions between two *other* addresses in the same transaction, the invalid-admin-error *can* occur:
I found out that the error occurs when in the order in the vouts ("n") of the transaction the 'revoke-entry' is before the 'grant-entry'.

---

Yes, you should put the grant entry before the revoke entry. That shouldn't be hard to do if you're building with raw transactions.