New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error choosing inputs for the send transaction #760
Comments
please try omni_send. Example: $ omnicore-cli "omni_send" "3M9qvHKtgARhqcMtM5cRT9VaiDJ5PSfQGY" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "100.0" https://github.com/OmniLayer/omnicore/blob/master/src/omnicore/doc/rpc-api.md#omni_send |
@congnghiakhiem is there a problem with omni_funded_send? Because I'm having the same issue with omni_funded_sendall. The from address has a tiny amount of BTC balance but the funding address has a lot of BTC. Any ideas about how to debug this? |
My I software requires me to use only one address to store btc and the rest to to store usdt. Therefore I was hoping to use omni_funded_send instead of omni_send in json api, because if there are bitcoins missing from source address, they are taken from the specified fee source. But I am stuck with the same error message lik @initsysctrl . The following was the output from json_rpc request: -- Request headers -- -- Request body -- -- Response headers -- -- Response body -- |
@congnghiakhiem The method "omni_send" must need bitcoin in the sender, which is not recommended after version 0.3.1. Because I need the sole payer of the commission fee.but also thank you. |
@dexX7 But it's still a question that why the code is implemented by that? wallettxbuilder.cpp: 231-234
|
@samueldeng The Omni Protocol spec stats that the 'sender' of a transaction is the address associated with the first utxo in that transaction. |
@achamely I have a situation where I have BTC in the send address (the minimum that I got when I received tokens) and there doesn't seem to be any way to use omni_funded_send or omni_funded_sendall. I always get "Error with selected inputs for the send transaction". The fee address does have BTC balance that is sufficient for tx. |
@alesito85 what are the 2 addresses you are using and the omnicore-cli command you are trying? |
Have same problem. feeaddress have alot of BTC, but i still have error: -212 Error choosing inputs for the send transaction |
The address has been verified and was valid and mine. What helps though is restarting the omnicored node. Strange, but it does... I've had plenty of balance everywhere and it didn't work. But when I've restarted the node the transactions were possible. And this was done multiple times. |
@rupsyde @alesito85 one other thing to note is that if your omnicore client is not fully synced it will not be able to properly use any balances it has not parsed yet. |
I've come back to this thread a few times because I was totally stumped, and think I may have figured out why a lot more people are seeing this than would be expected (including me). Pardon me if the language is a bit imprecise: You need UTXO’s in an OMNI address to send OMNI-layer transactions (not super surprising) out of that address. In practice, what this means is that if: you receive some USDT to a fresh address, and want to send some of the USDT out of that address you can do a “funded send” to pay the transaction fee out of a “fee address” you have (great!). However, what you then wind up with is an address that has some OMNI but no UTXO’s (you consumed it in the previous transaction). So now, even though you can pay the fee to send the remaining USDT from that address to another using “funded_send”, you can’t actually compose a transaction out of that address, since you have consumed the UTXO. So now you need to send some bitcoin (or whatever you want to do) to that address again to get it a UTXO, with which it can compose the funded_send transaction.
It seems like a great added feature of the OMNI protocol would be to, when composing a funded_send that is not going to send ALL the omni properties from a given address, address a UTXO back to the origin - conceptually like a "change" transaction... |
@litch right,This is indeed the case,and there's no better way to fix this than by sending bitcoin.That said, I can only send usdt or other omni'asset once,The second time will get an error,-212. Do you have a better plan? |
|
method: omni_funded_send, 1.address is valid token is enough |
This problem has been solved. When using the method omni_funded_send to send tokens, fromAddress should have a bit of btc.It means that the "feeaddress" does not pay all the fees. |
I confirm this issue still happen. |
The issue was occurred when sending 25 times on the same sending accounts. |
Quick fix by pass limit 25 transaction, should be add two configs to your command. or setting tether.conf |
I confirm this issue still happen. |
Still happen. |
@WilliamXie9 can you please specify steps how did you do that? Using raw-transaction RPCs, right? |
@dmitryrn sure
|
Anyone who searching for solution, I researched one. Idea is to use one address with big amount of BTC to pay transaction fees, one called Only issue with this is: if you have multiple addresses who want to make transactions using single And another issue: this use all of import a from 'axios'
const p = async (method, ...params) => (await a.post('http://localhost:8332', { method, params }, {
auth: {
username: '123',
password: '456'
}
})).data.result
const from = 'fromaddr'
const to = 'toaddr'
const feeSpender = 'feepayeraddr'
Promise.resolve().then(async () => {
const payload = await p('omni_createpayload_simplesend', 31, '1')
const unspentReceiverInputs = await p('listunspent', 3, 999999, [from])
const unspentFeePayerInputs = await p('listunspent', 3, 999999, [feeSpender])
const inputsUsed = unspentReceiverInputs.concat(unspentFeePayerInputs)
// 0.0000546 is tiny amount to send back to sender so it will able
// to send another transaction after confirmation of this one
const txBase = await p('createrawtransaction', inputsUsed, { [from]: '0.0000546' })
const txBaseWithPayload = await p('omni_createrawtx_opreturn', txBase, payload)
const txBaseWithPayloadAndReceiverOutput = await p('omni_createrawtx_reference', txBaseWithPayload, to)
const withChangeOutput = await p('omni_createrawtx_change',
txBaseWithPayloadAndReceiverOutput,
inputsUsed.map(({ amount: value, ...input }) => ({ ...input, value })),
feeSpender,
'0.00028865') // this is a tx fee
const { hex: signedTx } = await p('signrawtransaction', withChangeOutput)
const decoded = await p('decoderawtransaction', signedTx)
const txid = await p('sendrawtransaction', signedTx)
}).catch(r => console.log(r.response.data)) |
And please tell me if I can use more simplistic solution @dexX7 |
Hey @dmitryrn @WilliamXie9, can you quickly describe why/how funded send is not appropriate for your use case? In it's current form it consumes all BTC from the specified sender and transfers the specified amount of tokens (or sends any, if omni_funded_sendall is used). If not enough BTC are available for the send, the rest is taken from the specified fee source. However, there is always the need for at least one UTXO from the sender. |
@dexX7 The reason I can't use send/funded send is they does not leave UTXO on sender address (as I understand, I actually tested it). So in my method I create UTXO on sender address during transaction to be able to create another transaction from this address. |
Hmm.. is this for a token hot wallet or just for two sends in a row? If it's for a wallet, which is used multiple times, I'd suggest you could just send some BTC to it to keep it funded. |
Yes, send BTC to this address required sending transaction, and paying fees for it, but in my case another address pay fees and I don't want to manually send BTC to sender address after transaction. It will just have UTXO with tiny amount. |
@dmitryrn: what would you recommend, if we'd go to change the funded sending commands or add a new one? |
@dexX7 I guess people confused with situation like this: You have 2 USDT on your address and a bit BTC, then you send 1 USDT with And I'm not really sure what to do with that because it's default, like right, behaviour in bitcoin context. Maybe we just should create page on wiki with such use case? Or maybe we should add some description about UTXO in RPC description for I'm not sure about new method creation or changing existing one. |
mark |
this is quite a major issue to be completely fair. Even more when you need to split payments. Let's say you receive 2 USDT on address X You can't send them on the same TX as OMNI doesn't support sendmany, and you can't send the 2nd TX because you've ran out of UTXOs. There should be a way to solve this issue |
Yeah I wound up just solving this at the application level, as the protocol level aspect of this is feels a bit broken in that respect. Wound up working great in general, I just had to let go of my expectations that it would work a certain way.
|
Hey guys, initially the funded send was introduced to help exchanges to "sweep" all incoming tokens in one step without no leftover of bitcoins. So essentially what you need:
Is that correct? |
In my case BTC's UTXO was present in |
When I was planning to send USDT, there was an error. I am sure my balance of USDT&BTC is adequate.
The text was updated successfully, but these errors were encountered: