pull down to refresh
0 sats \ 0 replies \ @Filiprogrammer 5h \ parent \ on: A directory for a Monero circular economy monero
I just thought of another possibility: Someone trying to deanonymize the user could have deliberately sent them the 0.40156916 Bitcoin out of a coinjoin, hoping that the user would later send it to a KYC exchange, which they did.
This seems very unlikely though, since a much smaller amount could have been used. (dusting attack) Also if Wasabi Wallet 1.1.6 functioned correctly it should have marked this coin as non-private to the user.
Anyway this scenario seems very unlikely.
By the way, modern versions of Wasabi Wallet only show a maximum of 1 UTXO per address (even if the address actually holds multiple UTXOs), preventing you from spending multiple times from the same address.
I see. Outputs from two different coinjoins went to the same address:
https://mempool.space/address/bc1qxp8k4un9tzkm2phsvs22r26l6l2ny93tnts7nq
This should not have happened.
Based on the date of the coinjoins (7th of September 2019), we can assume that Wasabi Wallet 1.1.6 was used.
Two possible explanations for how this happened come to mind:
- Either a bug in the coinjoin output address selection of Wasabi Wallet leading to address reuse
- Or the user had two instances of Wasabi Wallet with the same seed phrase running and coinjoining at the same time.
The issue with scenario 1 is that I could not find any bug disclosure or fix for this.
That suggests either:
- Such a bug never existed in the first place.
- It was an extremely rare edge case that was never discovered.
- It was silently fixed, whether intentionally or unintentionally.
The issue with scenario 2 is that it is highly unusual to be doing that. It would likely result from either an intentional attempt to break things or an honest mistake. Given that the user also failed to notice the address reuse, user error seems plausible.
Because it's not capable of breaking deterministic links. It can be unpeeled by chain anal.
How? Any source supporting these claims?
And if you are worried about blocklists, the zkSNACKs coordinator was shut down in June 2024. Now the coordinators are run by community members.
In a coinjoin every participant has to sign the transaction. If just one participant fails to do that within the time limit, the entire process of input/output registration and finally transaction signing is restarted. So yes this does in fact happen. The higher the number of participants, the likelier it is to fail. You probably don't even notice when using Wasabi Wallet since all that happens automatically.
If you bring Lightning channel opens into the mix, then you have even more potential for failure. A Lightning channel involves two parties. So the other party also has to cooperate with the channel commitment in order for the coinjoin transaction to be signed by the participant funding the channel.
Yooo, that's epic! But this would probably take a lot of attempts when 100 people want to open a channel in the same coinjoin. But on a smaller scale this could be amazing!
Only 12 hours later another version is out already:
v2.5.1 Fixes a bug with the recovery workflow introduced in v2.5.0
in the future, i hope, almost all onchain transactions will be coinjoins
and batched Lightning channel open transactions
I've only heard of this but has it actually been implemented?
Not to my knowledge
It seems to suffer in that it incentivises letting hard to treat or chromic cases die, as they will never actually be healthy.
Yeah, I guess such a system cannot be applied universally.
You could pay a doctor/dentist to keep you/your teeth healthy. (Kinda like a subscription, but you only pay when you are healthy) When the patients are not healthy, the doctor makes less money. A doctor with a lot of healthy patients makes more money.
This way, the doctor is incentivized to keep you healthy in the long term.
Setting
--sat_per_vbyte 0 is like not setting it at all. The parameter is ignored when set to 0. Hence it chooses a fee rate on its own. The lowest you can go with LND is --sat_per_vbyte 1Don't be sad. Look at all the consolidation transactions getting mined now. Thanks to that the UTXO set has been shrinking over the past 40 days.
It seems cryptography isn't that difficult to learn.
Well... it's a lot of math ;)
Is there a difference when we say "Cryptography" and "Public Key Cryptography"?
"cryptography" is an umbrella term for "symmetric" and "asymmetric" cryptography.
Symmetric cryptography is used for encryption/decryption and there is only one key. (The key for encrypting a message is also the key for decrypting it)
Asymmetric cryptography (public key cryptography) uses a pair of keys. (private key and public key)
When encrypting a message with the public key, only the one who has the private key can decrypt the message. This is useful for secure communication.
When signing a message with the private key, everyone can prove with the public key, that the message must have been signed by the owner of the private key.
Public key cryptography can be split into 3 categories:
- Encryption/Decryption
- Key exchange
- Digital signatures
The cryptography that Bitcoin uses are digital signatures. These are used to proof that you actually have the private key to a transaction output.
This tool is mistakenly excluding taproot addresses with 0 outputs. But those do have their public key exposed, since the taproot address itself is the public key.
And it also does not list any P2PK addresses at all.
Anyway, quantum computers are still FAR away from becoming even remotely dangerous, so don't worry.
329 sats \ 0 replies \ @Filiprogrammer 29 Jan \ parent \ on: Watchtowers for public LN nodes lightning
The watchtower stores fixed-size, encrypted blobs and is only able to decrypt and publish the justice transaction after the offending party has broadcast a revoked commitment state.
0 sats \ 2 replies \ @Filiprogrammer 29 Jan \ parent \ on: Watchtowers for public LN nodes lightning
It can still make sense to use a watchtower with a private node. Your channel partner could still try to publish an old channel state onchain while your node is offline.