cgo: Add create signed transaction. #12
Conversation
asset/dcr/transactions.go
Outdated
| Amount uint64 | ||
| } | ||
|
|
||
| func (w *Wallet) SignSendTransaction(ctx context.Context, outputs []*Output, feeRate uint64) (signedTx []byte, txid *chainhash.Hash, fee uint64, err error) { |
There was a problem hiding this comment.
My understanding is that this method is supposed to create a signed tx that auto selects inputs to send funds to the specified outputs. I think it can be less complex if we follow the pattern in the dcrwallet jsonrpc fundRawTransaction method.
Basically, we just need to call w.NewUnsignedTransaction.
There was a problem hiding this comment.
Also, the method name is a little complex / confusing. CreateSignedTransaction?
There was a problem hiding this comment.
I think we will want to give an option to select inputs in this first iteration, so we will need the complexity anyhow. Let me double check.
|
SignSendTransaction -> CreateSignedTransaction https://github.com/itswisdomagain/libwallet/compare/fc33133e2f1db779c6f74deaecc323225d4695cc..57c6fce16722b9f42c51e915691184a3a12119ec |
|
Greatly simplified and able to pick inputs https://github.com/itswisdomagain/libwallet/compare/793fe5ef8597787a6da7e9882b3efea9b6823f4b..ca1b6ac9907942e187aacc7260af4aae51085511 |
JoeGruffins
changed the title
|
Sorry changing once more. We can also have frozen utxo. |
|
Now we can specify inputs to ignore as well. Looks messy again. Lightly tested. |
asset/dcr/transactions.go
Outdated
| // NOTE: This is not instantaneous and may take a few moments to send. Avoid | ||
| // closing the wallet directly after sending. |
There was a problem hiding this comment.
Should we add a delay in this method? I think if we don't, we have no way of preventing the user from closing the wallet immediately after a broadcast.
There was a problem hiding this comment.
I tested some more today and the wallet will send the tx again on the next start up. Because we don't have access to a dcrd with this info stored (mempool) I don't think we can know if it made it out onto the network unless we wait for a confirmation. So... no I think its fine. There's nothing we can know for certain without waiting too long.
There was a problem hiding this comment.
I'm going to remove the note.
| inputSource = func(target dcrutil.Amount) (detail *txauthor.InputDetail, err error) { | ||
| for _, utxo := range unspents { | ||
| if details.Amount >= target { | ||
| break | ||
| } | ||
| coinID := fmt.Sprintf("%s:%d", utxo.TxID, utxo.Vout) | ||
| if _, ignore := ignoreCoinIDs[coinID]; ignore { | ||
| continue | ||
| } | ||
| if !utxo.Spendable { | ||
| continue | ||
| } | ||
| if err := addUTXO(utxo, coinID); err != nil { | ||
| return nil, err | ||
| } | ||
| } | ||
| return details, nil | ||
| } |
There was a problem hiding this comment.
The other inputSource doesn't call addUTXO. It adds the utxos early on and simply returns details. Not sure which is better, they're likely the same thing but it'd aid consistency if both do the same thing. I'm leaning towards preparing the details outside of the inputSource fn. And that makes me wonder if it is possible to have a different fn prepare and return the details, so this one is less congested.
There was a problem hiding this comment.
I think I put it inside so that that we don't need to worry about calculating the fee. We can use the amount that dcrwallet calculates. The one where we do it outside just uses all the inputs and will error if it's not enough so not worrying about the amount at all.
There was a problem hiding this comment.
I guess it wouldn't be much work to estimate the fee, if you think we should. We could just copy whatever wallet is doing to make sure the amounts aren't different.
closes #11
Depends on all the other stuff atm.
Wallet logic taken from dcrdex.