feat: Implement u5c submit interface

[gonzalezzfelipe]

No description provided.

[SupernaviX]

Note that this interface isn't useful right now, because it only works if you pass in a complete TX and the txbuilder only builds partial TXs. I don't think tx3 will change that, based on santi's sample code

[gonzalezzfelipe]

Note that this interface isn't useful right now, because it only works if you pass in a complete TX and the txbuilder only builds partial TXs. I don't think tx3 will change that, based on santi's sample code

IIUC, the submit module is precisely for passing a complete tx. Tx building would be left to the client. Particularly, I added a function to pass a complete tx through the jsonrpc and submiting it that way. One could also send a Tx for it to be signed by a worker signer.

[SupernaviX]

Right, this interface is for passing a complete TX. I'm saying that because of the APIs balius exposes to the worker, it'll only have a complete TX to submit if that TX was passed into the worker from outside.

So this interface lets people write an endpoint like the one you wrote, which takes a transaction and submits it. But there's no way for the worker to build and submit transactions, which is why I'm saying it isn't useful. If the caller has a signed transaction and a demeter key, they probably have access to a "submit transaction" API already, and balius isn't buying them much.

[gonzalezzfelipe]

Right, this interface is for passing a complete TX. I'm saying that because of the APIs balius exposes to the worker, it'll only have a complete TX to submit if that TX was passed into the worker from outside.

So this interface lets people write an endpoint like the one you wrote, which takes a transaction and submits it. But there's no way for the worker to build and submit transactions, which is why I'm saying it isn't useful. If the caller has a signed transaction and a demeter key, they probably have access to a "submit transaction" API already, and balius isn't buying them much.

Why is there no way for the worker to build the transaction? I understand a tx builder would make it easier, but its doable now. Even so, this is the shape that the interface will take, with or without tx builder. Should we not implement it till we have a way of building txs?

[SupernaviX]

Why is there no way for the worker to build the transaction? I understand a tx builder would make it easier, but its doable now.

It's technically possible to build a TX without a TX builder, but it's hard enough to do that it's practically impossible; you'd end up writing your own TX builder inside of the worker, reimplementing balancing and fee estimation and everything else yourself.

Even so, this is the shape that the interface will take, with or without tx builder. Should we not implement it till we have a way of building txs?

Yeah, that's all I'm saying. I don't think there's a point to implementing the interface if there isn't a way to use it.

[Benja272]

Hi, i think this PR makes more sense right now considering that the idea is to include tx3 building (my understanding) . I am exploring the capabilities of balius and i think this is definitely useful.