Store non-hased tx in contract

[janmichek]

For now I am storing it in off chain database

SDK functionality request aeternity/aepp-sdk-js#1534

• add test scenario for reading amount and recipient from contract

[marc0olo]

@janmichek I don't think that's correct. if so that's more an issue of the SDK. we should be able to decode the tx-hash and read the raw data of it.

can somebody check/confirm? @davidyuk @subhod-i @thepiwo

[janmichek]

Seems not to be possible (at least at the moment) https://devchat.aeternity.com/channel/javascript-sdk?msg=94QHK9vN3pnHENMi2

[marc0olo]

Seems not to be possible (at least at the moment) https://devchat.aeternity.com/channel/javascript-sdk?msg=94QHK9vN3pnHENMi2

can you post the message here instead of linking to it? would be good.

if this is not supported by SDK it should be added, shouldn't it?! @davidyuk @subhod-i

actually I can't believe this is not possible right now 😓

[janmichek]

@marc0olo reasoning copied into the initial post

[janmichek]

I have updated this.
Turned this ticket into adding a test.
Added request on SDK guys with attached issue there

[janmichek]

After the consultation with @davidyuk
We propose to store non-hashed tx into contract.

As I know, you can't extract it from testSpendTxHash (because of hashing), but can extract from testSpendTx, so I proposing to put testSpendTx into contract for simplicity

[marc0olo]

I think I discussed with @thepiwo shortly that we don't store the non-hashed tx into contract as it has no relevance for verification. the non-hashed tx can be passed to other participants in another way (fetching from a backend or sending to other uses directly in whatever way)

when I remember correctly the backend was already developed and can be used, right?!

[thepiwo]

This has not been developed yet, but shouldn't take too much time

[davidyuk]

My idea is to be more decentralised by not using backend. Then we can host multisig frontend in ipfs and so on. The extra transaction storage costs not so significant to create a backend, I think.

[marc0olo]

My idea is to be more decentralised by not using backend. Then we can host multisig frontend in ipfs and so on. The extra transaction storage costs not so significant to create a backend, I think.

let's discuss this again when we decide to continue developing the multisig application. currently it's still on hold. I get your point.

the only drawback having it public in the contract is that everybody will know what the tx is about before it's being broadcasted

[janmichek]

We should resolve it by the conference as I will be presenting this.
Or we can do a 'fake' demo. From user's perspective, there will not be any observable change.

[marc0olo]

the only drawback having it public in the contract is that everybody will know what the tx is about before it's being broadcasted

actually this is also the case if we have a public backend. but there we could add some logic where a signature of the multisig participants is required to fetch the raw-tx if we consider this as a requirement.

[davidyuk]

Let's have raw tx encrypted with a symmetric key defined at contract creation. Contract creator can put this key encrypted for each participant, this should cost the same as storing participant addresses.

[marc0olo]

Let's have raw tx encrypted with a symmetric key defined at contract creation. Contract creator can put this key encrypted for each participant, this should cost the same as storing participant addresses.

actually I like this idea. what do you think @thepiwo ?

[thepiwo]

@davidyuk then the symmetric key has to be shared somewhere of the record, that keeps the same problem. Asymetric could work, but including the (encrypted) raw tx will always cost more as storing participant addresses. Additionally this would include change of contract logic. I would propose to go the simplest way first instead of overengineering.

[marc0olo]

I would propose to go the simplest way first instead of overengineering.

good point. let's start simple. also we have versioning of the contract set up so that if we decide to update the contract at some point the frontend will be able to handle this by fetching the version info

[davidyuk]

then the symmetric key has to be shared somewhere of the record

Not necessary, for example:

• participant A generates a symmetric key;
• encrypts it for participants B, C, D, A (using their public keys);
• puts encrypted keys into smart contract init function.

Then each participant can

• decrypt the symmentric key using their private key;
• encrypt a transaction using it and push to smart contract.

Other participants will be able to read it securely 🤔. Probably a nonce needed and the tx hash should be aploaded separately. To not overcomplicate it is also fine, but do not hurry to introduce a backend here 🙂

[thepiwo]

A backend is not necessarily needed, the raw tx can also be shared with any other service, e.g. an additional smart contract, QR code scanner, chat msg...