Open Bonzbonanza opened 5 months ago
Hey @Bonzbonanza, thanks for the report.
It is not totally clear to me, what is actually happening. Could you please be more specific of what you want to achieve? e.g. if funds are frozen, you should be able to unfreeze them from the Jar Details view (click on any jar in the dropdown of the home screen). Or is it related to a fidelity bond? What does "Confirmed lockup period is prior to the confirmation block." mean exactly?
Thanks, and please forgive me for not understanding it straight away. :pray:
Thank you for the reply! My apologies for being unclear.
I wanted to unfreeze the funds but couldn't figure out how to do so. It is not intuitive how to do this. Thank you for the suggestion, which worked.
I was trying to say that I did not purposely freeze the funds, especially by using a Fidelity bond, so "Confirmed lockup period is prior to the confirmation block" refers to the fact that the lockup time for the transaction was in the past and not the reason for the freeze.
It is still concerning that the funds were locked in the first place was whatever caused it was not something that I selected.
Please know, that fidelity bonds are unable to be moved and locked by the Bitcoin protocol. They do not participate in collaborative transactions.
So, is it a fidelity bond utxo you are talking about? Fidelity bonds are frozen in order for them not to be used accidentally, once the locktime expires. Additionally, if you reuse an address the UTXOs are frozen automatically as a privacy preserving measure. Since you can always freeze and unfreeze them (except fidelity bonds that are not expired yet), what do you mean with "concerning"?
If you used a pristine address that has never received any funds before and the UTXO is subsequently frozen automatically, then this would be a bug. But I highly doubt that this is the case here. Can you confirm?
Yes, actually, that is what I'm confirming. This was an unused address in a new installation. That is the concerning part. Two incoming transactions to two different jars with two different addresses in a brand new wallet were frozen. I understood the warning to wait for 5 confirmations though I did try, as it said I could, to send to a collaborative transaction before 5 confirmations. Those failed, and they still gave a warning about being frozen though the snowflake didn't show up until after the reboot. At that time there was no option to try a collaborative transaction at all, but I was able to find the option to unfreeze with your help.
There was never a fidelity bond (not least because the order book shows no activity so I'm unwilling to tie up funds).
-------- Original Message -------- On 6/21/24 2:18 PM, Thebora Kompanioni wrote:
Please know, that fidelity bonds are unable to be moved and locked by the Bitcoin protocol. They do not participate in collaborative transactions. So, is it a fidelity bond utxo you are talking about?
DuckDuckGo removed one tracker. More
Please know, that fidelity bonds are unable to be moved and locked by the Bitcoin protocol. They do not participate in collaborative transactions.
So, is it a fidelity bond utxo you are talking about? Fidelity bonds are frozen in order for them not to be used accidentally, once the locktime expires. Additionally, if you reuse an address the UTXOs are frozen automatically as a privacy preserving measure. Since you can always freeze and unfreeze them (except fidelity bonds that are not expired yet), what do you mean with "concerning"?
If you used a pristine address that has never received any funds before and the UTXO is subsequently frozen automatically, then this would be a bug. But I highly doubt that this is the case here. Can you confirm?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Okay, thanks @Bonzbonanza. If you are totally sure that this is what happened, would you be able to open an issue at https://github.com/JoinMarket-Org/joinmarket-clientserver
Jam is just a UI and cannot do anything about it. Thank you :pray:
Expected behavior
Funds availability after 175 confirmations
Actual behavior
Two jars have frozen funds
Steps to reproduce the problem
Specifications
Version: 0.2.0
Platform: umbrel umbrel_jam_2024-06-20_18-59.log
Browser: Safari
Additional context
Confirmed lockup period is prior to the confirmation block. Jam logs don't look helpful but are attached. I did notice the following line in the umbrel log file: "Jun 20 21:32:00 umbrel umbreld[3380]: time="2024-06-20T21:32:00Z" level=warning msg="/home/umbrel/umbrel/app-data/jam/docker-compose.yml:
version
is obsolete""umbrel_jam_2024-06-20_18-59.log