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.