multi: Enable staking on trezor.
Opened this issue · 12 comments
This purpose of this issue is to track changes needed to enable staking through decrediton on the trezor hardware wallet.
Depends on changes tracked by #2680
Staking also depends on changes being merged in the trezor firmware. Those changes are here:
trezor/trezor-firmware#1249
Work on this in decrediton cannot begin until the above two changes are completed.
Ticket purchasing on testnet has been reliably achieved using a combination of these diffs with the above firmware changes:
trezor/trezor-utxo-lib#9
trezor/connect#678
matheusd/trezor-decred-poc#6
Related to #1491
We have to decided to roll our own firmware as we wait for Trezor to merge. #2705 is in so we can continue. We were not able to get firmware updates working in that pr, so there will be an intermediate pr to get that working, then this issue can be solved for those who wish to use custom firmware rather soon I believe.
Every once in a while people ask about the status of Decred staking with Trezor. This is the most relevant issue I could find. Having a short status for 2022 would make it a good reference to link to.
All work on the trezor side is done actually! Will update this OP after a refresh on what still needs to be done over here and in dcrwallet.
Well, I thought trezor was done for staking, but there is a bug in version v2.5.1 through v2.5.3 and am trying to get fixed here
#3848 allows purchasing on testnet. There is already a follow up pr ready that handles creating a new voting key that will allow vsps to vote for the trezor with deterministic voting addresses based on data produced from signing a message with the trezor.
The last piece that is still in development is error handling when fee payment does not go smoothly. I would like to handle this in decrediton, since it will require the user's input to attempt to re-pay a fee. We cannot do this passively in dcrwallet as I believe is the case normally.
dcrwallet's VSP client (or the autobuyer?) has machinery for tracking VSP tickets throughout their lifecycle, doesn't it handle failed fee payments already?
You have to pay the fee with trezor. So you have to confirm the signing of the transaction on the device. You can't just leave it unlocked like dcrwallet.
The fees for the vsp are valid for a certain time window. So if you need to re-send the tx fee later, that is a new transaction that requires physical input from the user.
any way to help out here? looks like just waiting on trezor/trezor-firmware#2703 - happy to test, etc. thanks for getting this hooked up!
This is a perpetual waiting game.
You have to pay the fee with trezor. So you have to confirm the signing of the transaction on the device. You can't just leave it unlocked like dcrwallet.
The fees for the vsp are valid for a certain time window. So if you need to re-send the tx fee later, that is a new transaction that requires physical input from the user.
Could you also clarify why single transaction can't bundle both: ticket-buy and fee-payment (just to confirm my hunch that ticket-buy must specifically have exactly 1 input and 3 outputs) ?
Another potential way to get rid of the need to confirm VSP fee payment transaction on Trezor would be to have a temporary Decrediton-owned wallet, if you still have to do a split transaction anyway (to prepare the input to buy a ticket) which requires approval on Trezor - might as well create a separate output to pay into Decrediton-owned wallet so it can pay VSP fee later automatically without additional confirmation from the user (I'm assuming VSP fee is payed after ticket-buy transaction is issued, maybe we can pay it even earlier - wasting it shouldn't be a huge deal either way). I didn't research this deep, but that probably requires adjusting the way split transaction is generated in dcrwallet.
Could you also clarify why single transaction can't bundle both: ticket-buy and fee-payment (just to confirm my hunch that ticket-buy must specifically have exactly 1 input and 3 outputs)
We must inform the vsp of our fee transaction and current vspd logic cannot handle that. It would be a lot of changes in a few repos.
Another potential way to get rid of the need to confirm VSP fee payment transaction ...
Yeah, but it's only a couple clicks. Hours of dev time and adding code that can add more bugs and more dev time for a not so great return.
The message confirmations were really awful, and I think the extra dev time to get rid of those was worth it. But one extra transaction confirmation is not such a big deal imo.
Also, I hope the first implementation that closes this issue can be simple. Improvements can be made from there.