New TMSP request type BroadcastTx?

[mdyring]

It would be very useful to be able to propose transactions via TMSP, as it seems a bit unnatural having to resort to HTTP to accomplish this.

Maybe a separate connection could be established for this in addition to mempool/consensus?

[ebuchman]

not sure I understand. what's the use case? when a transaction is received via HTTP (the standard way for users to communicate with daemons these days), it is run through the CheckTx msg of TMSP. if its valid, and will be added to the mempool and gossipped to peers, becoming eligible to be included in a block. if its included in a block, it will be executed via AppendTx. What would ProposeTx do?

[mdyring]

Use case is that one of the TMSP apps (running independently on the tendermint nodes) wishes to _initiate _ a transaction. In that case, it would be nice not having to introduce a HTTP client dependency in the TMSP application, as well as it feels more natural to just use the protocol already in use.

So ProposeTx (in lack of a better word) would act similarly as the HTTP RPC method.. Just via TMSP instead.

[ebuchman]

Ah yes, I've dwelt on this before. the current design is such that all messages are initiated from the tendermint side, which is why we have no support for something like this yet. but you're right, perhaps a third connection, which allows the app to send transactions to the core without going through HTTP is a good idea. Thanks! Are you on our slack?

[mdyring]

Yes, I think maybe a 3rd connection (which could be optional, i.e. a listener in the tendermint node?) would be cleaner.. So that the request/response pattern also makes sense.. TMSP app as a client send request ("ProposeTx") and receives a response.

Currently testing tendermint/tmsp against a C++ app (using boost/asio/protobuf), seems very promising.. Nice work :-)

I am not on slack.. Let me know how to jump onboard.

[ebuchman]

Awesome! Either give me your email or email me at ethan@tendermint.com and I'll invite you.

[jaekwon]

Transactions for the same or different blockchains? Can you provide a more detailed use case?

[mdyring]

I'll summarize that we discussed earlier and the benefits I see.

• The suggested feature complements the broadcast_tx HTTP RPC
• There are a number of scenarios where a TMSP app might want to broadcast new transactions and not just verify/consume them, basically any TMSP app is talking to the "outside world"
• It seems natural for a TMSP application to be able to do all its work using TMSP only - not all programing languages come with a HTTP client handy so it would lower barrier to entry to use TMSP as lingua franca as well as make the TMSP offering more complete
• In some environments (high tx throughput) I imagine TMSP will be much more performant than HTTP
• Size limits.. I haven't checked if the HTTP RPC accept POSTs, but if not there will be a fairly low limit on the transaction sizes that various HTTP stacks will be willing to accept as GET URL parameters

More specifically, I suggest to add a TMSP listener to the tendermint core, that will accept a connection from the TMSP application and accept BroadcastTx requests. I do not suggest to implement the full HTTP RPC feature set for TMSP, but restrict it merely to broadcasting transaction. To me it seems the HTTP RPCs that are related to management/monitoring should stay HTTP.

[mdyring]

Ideally, this could be solved by providing a GRPC interface for BroadcastTx alongside #212

[silasdavis]

Another use case for this is for when one wants to use a Tendermint node in a 'slave' or 'harnessed' mode to some master gateway, which handles external requests. For us the ideal situation is that we would talk exclusively to Tendermint over a private socket connection (using TMSP). Not only to receive Tendermint API callbacks on, but also to push transactions through as an alternative to the HTTP RPC, which we would like to disable in this case.

The reason being, as well as some minor efficiency issues is that we don't want our Tendermint node to accept any requests originating from other entities that happen to be on the same network. We can simply permission a Unix socket to do this. There are other workarounds we could use, but it would be cleaner to support a private 1-to-1 bidirectional connection for our use case.

[tomtruitt]

I'm confused by this because thought only requests from the known validators and participants are accepted?

[silasdavis]

Only known validators can propose blocks, but if we're talking about tendermint alone, I think anyone can push transactions, from the wiki:

Peers can then connect to the network by simply knowing the ip:port of a validator, or another peer, for example, by running tendermint node --seeds ip:port

Also I think any checking that does occur is done by checking signatures, which is a different layer to connection level authentication (I think we want both)

[ebuchman]

you can run the tendermint rpc over a private unix socket! is that not sufficient? pushing txs over tmsp in the other direction is non-trivial and somewhat counter intuitive. what if you need other information from tendermint core? maybe you want to know about the network, or the current state of consensus, or otherwise. do you expect to get all that information via tmsp as well? this is what the rpc is good for, and you can run it on a private unix socket no problem, or just bind to localhost so only other things on that machine can access. or use docker networking. many options here.

[silasdavis]

I can run the RPC over a private unix socket... how would I configure this?

[ebuchman]

in the tendermint config file you can specify the rpc_laddr. just set it to the socket file you want to use. then connect over that from erisdb.

[mdyring]

To me the best important part of the proposal is not so much to run everything over a single connection or in one "direction" (connection wise) or even the security implications of doing so.

My primary reasoning for the proposal is that that it feels very unnatural to have a separate communication channel (well, protocol actually) for something that is required to do anything meaningful - propose a new transaction. It should be possible using the same mechanism as check/appendtx, so either TMSP or the gRPC.

Actuallly implementing gRPC interface now and I think I will put on "Boy George - The Crying Game" once time comes to pull in a 3rd party HTTP/WebSocket library in C++ just to broadcast TXs.

[ebuchman]

btw, why isn't just binding to localhost sufficient?

[ebuchman]

lol martin. would you instead put on "Pharel - Happy" if we move the rpc lib to use grpc as well?! that's something we can defntly do, once there's time ...

[mdyring]

Yeah, it seems a hassle (for me and you guys) to provide X number of different ways of talking to tendermint core. So moving the RPC stuff to gRPC would be great - it seems to do a fairly good job at it.

[tomtruitt]

Lmao

[mdyring]

Ethan was kind enough to implement this in grpc branch.

See #221 for a few additional changes to build successfully (+ fix bug in gRPC/Protobuf somewhere).

To build uses the steps from README.md (git clone + glide install), not the "go get" approach.

[tomtruitt]

You can't go get this?

[mdyring]

I don't believe so. Doing a git clone + glide install will ensure that the latest gRPC + Protobuf dependencies are pulled in.. See the PR.

I haven't tested the go get method, but it appears to be obsoleted judging from README.md. I have opened https://github.com/tendermint/tendermint.github.io/issues/4 to update the tutorials.

[ebuchman]

Seems the main need here has been addressed with broadcast_tx via grpc. Closing this for now.