You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 15, 2024. It is now read-only.
tx__ is quite useful to locally sign a transaction then send it for inclusion.
The client api has a "forward transaction" endpoint for that.
However, type 4 txs (vote) do not follow the same data structure as usual transactions and can't be encoded the same way.
Thus, we'd like to suggest a new nyzostring type - tx4_ for instance - that would represent a type 4 signed vote tx.
"Forward transaction" endpoint could then handle both tx__ and tx4_.
The text was updated successfully, but these errors were encountered:
This has been corrected on https://client.nyzo.co, and the fix will be released as version 584.
The problem was actually in the run() method of TransactionForwardCommand. In building the result table, a NyzoStringPublicIdentifier was built with the receiver identifier of the transaction. This field is null for a cycle-signature transaction, and a null-pointer exception was thrown. This caused the "Unexpected issue forwarding transaction..." error.
Version 584 is already live on client.nyzo.co, so it is now able to forward cycle-signature transactions.
This issue has been corrected with the release of version 584. While a new Nyzo string type was not added, the current Nyzo transaction string supports all transaction types, and the issue of forwarding type-4 (cycle-signature) transactions was corrected.
Nyzo Strings currently define:
Micropay("pay_")
PrefilledData("pre_")
PrivateSeed("key_")
PublicIdentifier("id__")
Signature("sig_")
Transaction("tx__")
tx__
is quite useful to locally sign a transaction then send it for inclusion.The client api has a "forward transaction" endpoint for that.
However, type 4 txs (vote) do not follow the same data structure as usual transactions and can't be encoded the same way.
Thus, we'd like to suggest a new nyzostring type -
tx4_
for instance - that would represent a type 4 signed vote tx."Forward transaction" endpoint could then handle both
tx__
andtx4_
.The text was updated successfully, but these errors were encountered: