Skip to content
This repository has been archived by the owner on Feb 24, 2023. It is now read-only.

blockchain.transaction.relayable / status? #87

Open
monsterbitar opened this issue Aug 3, 2020 · 3 comments
Open

blockchain.transaction.relayable / status? #87

monsterbitar opened this issue Aug 3, 2020 · 3 comments

Comments

@monsterbitar
Copy link

I had a talk with shammah about how he uses electrum for stamp, and we identified a feature that might be good to have: checking if a transaction is relayable or not.

For the case not, it could be due to it being a double-spend, or not matching standardness, or too low fee etc.

The call would take a hex-encoded raw transaction, or an array of such, and then return information about the transactions validity / relayability. It would be particulary useful in places that works with off-line transactions where part of the check for validity is that it's unspent and valid according to the network itself.

Input: Array of raw transactions, and optional broadcast flag.
Output: Boolean for total outcome, array of txid:bool, and optional broadcast txid.

It might be possible to include this functionality as part of #86 (both as a standalone blockchain.transaction.status and as a subscription), rather than making a separate feature.

@cculianu
Copy link

cculianu commented Aug 3, 2020

Note that the corresponding discussion in Fulcrum here is also relevant: cculianu/Fulcrum#44

In particular we may want to not specify an array of tx's, but have it just be 1-tx-per-call.

The usefulness of the array is limited considering bitcoind's testrawtransaction API can only accept 1 tx-per-call anyway, so it's not like you can test the tx's together as a set or anything, and Fulcrum's internals would be very grateful if it were 1-tx-per-call because it makes it easier to ensure no DoS attacks here (due to the way Fulcrum's internals work).

Anyway @monsterbitar agrees to my 1-tx-per call suggestion here... so. Just writing here to inform the discussion of that fact.

@cculianu
Copy link

cculianu commented Aug 3, 2020

Note that testmempoolaccept returns the following information:

 {
  "txid"           (string) The transaction hash in hex
  "allowed"        (boolean) If the mempool allows this tx to be inserted
  "reject-reason"  (string) Rejection string (only present when 'allowed' is false)
 }

@rnbrady
Copy link

rnbrady commented Sep 2, 2020

Thanks @monsterbitar for linking here from Twitter thread re DSPs and Electrum Cash Protocol. I have opened dagurval/electrum-cash-protocol#22 to discuss DSPs specifically.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants