pull down to refresh
These worries are unjustified. AI can hack together some buggy code for a very basic program. But tell it to write some device driver for Linux and it will fail completely.
We can lower the value of
max_accepted_htlcs to prevent flooding of a node with HTLCs.
Also the bad actor will have to keep opening new channels to make others lose money. And opening channels incurs an on-chain fee. So the bad actor has no monetary gain out of it, it actually costs them sats too.But I do agree that this is a theoretical problem
I remember reading a proposal for an Offchain Payment Resolution (OPR) protocol where an HTLC does not add any outputs to the channel state transactions:
https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233
This is ideal for small payments. I can actually see a future where we use a combination of OPR for small payments and the existing Poon-Dryja payment channels for larger payments.
Edit: The author made a 1.1 version going into more detail: https://github.com/JohnLaw2/ln-opr/blob/main/opr_v1.1.pdf
No, zapping over the Lightning network does not create an onchain transaction. And also the channel opening transaction will never confirm if you replace it, as I mentioned in step 2.
Fun fact: You can actually setup a hosted channel between two LND nodes in a convoluted way:
- Create a zero-conf channel with
--sat_per_vbyte 1, so it does not immediately confirm - Replace the opening transaction
No, you still mine with the Ocean Pool. But you get to decide which transactions go in the block in the rare case that you hit a block.
You build your own block templates without relying on the pool. Meaning you decide which transactions get mined.
Maybe Trump really didn't know any better. Then he should have done his due diligence before promoting something.
Maybe he should have stuck to BTC!
Yes, for sure!
Not sure if he pulled the rug but launching a meme coin where 80% is held on one wallet is already very shady. And promoting something like that as a president, preying on people who will fall for it and get burned, is very unethical.
If they only had the seed and nothing else, it might buy some time. But if they also have access to a watch-only wallet, then they can see your derivation path, which is usually not sensitive information.
You are better off using a passphrase instead.
Interesting idea but showing it off in plane sight sounds risky to me. This is not encryption, just encoding. It's security by obscurity.
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.