During my last tests, G1nkgo 0.2.5-SNAPSHOT doesn’t get anymore comment from payment QRcode
For exemple :
which is of that kind june://DESTINATIONPUBKEY?comment=PREFIX:COMMENT
Is it because amount is needed ?
NB: This QRCode is produced and used by “G1 VOD Service” i am working on. So shown wallet monitors receiving payments with such comment then operate an action based on it. In this case (PREFIX=N1Kodi) it send back through Cesium+ messaging a link to watch a video.
I was these days trying to find a way to workaround this that without doubt is the main current issue of g1nkgo.
To summarize, currently you cannot make fast concurrent payments in G1nkgo (something common in a gmarket), and subsequent fast payment are marked as failed and you have to retry later, manually.
The situation is that currently, GVA basic genTx have a simple interface (issuer, recipient, amount, comment) and if I’m not wrong, you cannot select the sources/inputs:
If I send several payments in a short time using a gva node, as @kimamila mentioned, only the first payment is well processed (I was hoping that the duniter gva node, with this interface, will deal with the whole payment processing of sources, etc, but I was wrong).
In the past I opted to use random gva nodes on each payment with the (silly) hope to workaround that.
I also added the retry/failed-payments stuff to don’t lost payments.
Then, I’m trying now to do a more complex/advanced payments take into account the UTXOs. I have the first part more or less done, that is, retrieve the utxos of a pubkey and calculate for a payment which utxos to use, mark as consumed, and allow to do other payments without use that previously consumed utxos.
This weekend I implemented this part (in durt and g1nkgo) but now I need to do the tx with the selected utxos as inputs.
There is an additional genComplexTx that it sounds to me that maybe can do the job of do such a payment (correct me):
I think you should use mempool utxo for transactions in Ginkgo, that should solve your tx problems.
The only case this would make problem is if the mempol used utxo failed to validate in blockchain.
Maybe we should make unit test to compare and choose the best case.
I made a MR for that if you want.
I also published Durt 0.1.7 with you latests changes.
I see that you get utxo from accounts in ginkgo but not sure to understand why you need it since you use GVA to generate de transaction document, by choosing sources and generate changes transactions itself.
If the way GVA choose the utxo himself still have problems, you still can generate the transaction document yourself by choosing utxo with changes transactions, GVA makes it possible, like Cesium and Silkaj do with BMA, but it’s a bit of work to add in Durt, and I never made this kind of thing myself so I could not help.
If you have to make a lot of transactions to debug your work on Durt, you can use durt_cli, i made especially to try and debug durt. It’s a really simple cli tool which use durt lib, usefull if you want to loop things with bash …