I created a thread asking people what they think bitcoin will stabilize enough to become a currency for people to use and literally everyone said to me that it's an asset and it will never stabilize. All you've discovered here is that Bitcoin Discussion is filled with spammers and bad place to try to have any intelligent conversation about bitcoin.  Recently I tried to sell my crypto without KYC and I didn't find any good platforms to do it! Here are 20+ to choose from: https://kycnot.me/ |
|
|
|
If you are interested to know why these are the limits, you can read the relevant code starting here: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L26The dust limit is 3000 sat/kvB, or 3 sats/vbyte, of the minimum amount of data required to spend that type of output. For a legacy P2PKH transaction, then an input is 148 bytes, and an output is 34 bytes, giving (148+34)*3 = 546 sats. For a segwit v0 P2WPKH transaction, then an input is 67 bytes and an output is 31 bytes, giving (67+31)*3 = 294 sats.* For any script hash or taproot outputs, however, then the size of the input is not known in advance, since the locking script is not revealed until after the transaction is made. So instead we use the size of a standard input, and the size of the specific output. So for a taproot P2TR transaction, then an input is assumed to be 67 bytes and an output is 43 bytes, giving (67+43)*3 = 330 sats. *This should actually be 297 sats in reality, but a rounding error means that 67.75 is rounded down to 67 instead of up to 68. |
|
|
|
I think we all know about the Wasabi debacle, but my goodness, Trezor is surveilling stuff too? They have partnered with Wasabi and implemented Wasabi's permissioned and censored coinjoins directly in to Trezor suite. |
|
|
|
From my understanding of Trezor's architecture the private key never leaves the chip -- the firmware is only able to send messages in and getting signed messages out. Which is exactly what Ledger said about their secure element. At the end of the day, the hardware, software, and all the architecture is designed and built by a single entity, and if they wanted to extract your private keys, they could. If Trezor's microcontroller was actually impervious to such attacks, then why are they trying to build their own secure element? |
|
|
|
I'm not going to rehash my statements from the main thread about this, as I've been pretty clear over there what a complete disaster this is and how Ledger have obviously been blatantly lying in the past. In my opinion no one should ever touch another Ledger device again. However, why are we singling out this even for an important announcement? Why no important announcement about Trezor's unfixable seed extraction vulnerability? Why no important announcement about Trezor/Wasabi's government sanctioned surveillance and censorship? Why no important announcement about Coinomi sending seed phrases to Google servers? What about Block's hardware wallet which is specifically built on this exact idea of sending your seed phrase to a bunch of third parties? And if people are so concerned about the fact your private keys can be extracted from the secure element in Ledger wallets, then what about all the hardware wallets which don't even have a secure element in the first place? They are just as risky. There are a plethora of critical vulnerabilities and horrible business decisions out there that we don't have announcements about. Why do we need an announcement about this one specifically? |
|
|
|
But at this point with Ledger's statement, all devices (even coldcards for example) that have the same secure element chip are vulnerable or am I wrong? You are correct. All Ledger devices use the same internal framework, and we know that it has been possible all along for the secure elements to export private keys, which is completely contradictory to all the claims Ledger have previously made. In theory, unless you update to the newest firmware that unlocks seed-share and approve it physically by pressing the buttons on your Nano, the feature won't work. Which is completely irrelevant. Given that a simple software update means the secret element can now export private keys, then a simple software update could make this feature mandatory, or could remove the need for any physical button presses, or could take everyone's private keys without their knowledge or consent. The whole point of the secure element is moot. The entire security of the device hinges on non malicious software. It's probably worth pointing out that this is also the case for Trezor devices, which everyone on Reddit seems to be keen to move to. If Trezor implement malicious software, then the same thing will happen. The only hardware wallet I would even think about touching right now is a Passport - permanently airgapped and completely open source - but as I said before, airgapped, encrypted, cold storage on an old laptop or similar is far preferable. |
|
|
|
Say that even if we've got the old nano s but they can still try to do something and update and force an update for its firmware, is that right? An update is irrelevant. As I explained earlier in this thread and in the tweet just above, the whole point of Ledger's Secure Element was that the private keys could never leave the Secure Element. We now know that claim is a lie, and has therefore been a lie since day one. A simple piece of code is all that is required to extract your private keys. All Ledger devices are vulnerable whether or not you opt in to this or update to the latest firmware. |
|
|
|
Tweet by Ledger from 6 months ago: Hi - your private keys never leave the Secure Element chip, which has never been hacked. The Secure Element is 3rd party certified, and is the same technology as used in passports and credit cards. A firmware update cannot extract the private keys from the Secure Element. Lol. |
|
|
|
It might not be directly related to security, but it is still a massive issue that Trezor fund government sanctioned surveillance and censorship. Security is in ensuring that the private key is generated in a way that does not and will not connect to the Internet or that it is shared in one way or another with third parties, something that has not happened in Trezor. Note that all Trezor devices have an unfixable vulnerability which means your seed phrase can be extracted from the device. If you are worried about this on Ledger devices, you should be just as worried about it on Trezor devices. Trezor and Ledger are both very poor choices of hardware wallet. |
|
|
|
|
I'm going to agree to disagree here. A non-custodial wallet should be one in which I, and I alone, have access to the private keys. If someone else also has access, then I wouldn't call that non-custodial. If you can't prove that no one else has access (as is the case with every closed source wallet), then I also wouldn't call it non-custodial.
It's not a perfect categorization, but that's what happens when we apply binary labels like custodial/non-custodial or hot/cold to wallets. The safest wallets are non-custodial wallets in which I exclusively hold the private keys, and that is provably the case. Everything else should be classified as custodial so we do not muddy the waters by people using closed source wallets in which they think they have exclusive access to their private keys, and then wondering why their seed phrase was sent across the internet to Google servers and all their coins were stolen.
|
|
|
|
but honestly, some of their explanations were all over the place, not really addressing the tough questions head-on.
...
I'm left feeling like there's a whole lot of smoke and mirrors going on. This exactly. The fact that none of the devs have actually just directly answered these questions head on in a couple of sentences, and are instead making people sit through an hour long recording, speaks volumes. It reminds of that quote from Vitalik about known scammer CSW: In general, signaling theory says that if you have a good way of proving something and a noisy way of proving something, and you choose the noisy way, that means chances are it’s because you couldn’t do the good way in the first place. Does it mean we can't verify that they have no access to the decryption key used to reconstruct the initial seed? It is still unclear how the whole decryption process works and how a hardware wallet knows that you underwent a KYC procedure to start recovering. Who sends it a decryption key because it may be a different device from that you created your setup? It's not clear yet, but we know they must have the means to decrypt it themselves. You can lose your hardware wallet and your seed phrase, and still recover your wallets on a new device. This means that everything needed to recover your seed phrase (i.e. the shares and their decryption keys) are stored by one or more third parties, since you need to provide absolutely nothing yourself, not even the original device. |
|
|
|
What happened with Trezor? I remember a seed extraction hack from a couple years back, but that one still required physical access which makes it not even nearly as bad as what Ledger is doing. That, and their partnership with Wasabi and blockchain analysis firms, resulting in government sanctioned surveillance and censorship. |
|
|
|
I think maybe there were no pending transactions from the network There are in excess of 60,000 unconfirmed transactions in the standard mempool at the moment, and in excess of 250,000 if you include all the ones which have been dropped due to memory or time limits. There is absolutely no shortage of transactions to be mined. or all pending transactions already taken by other pools That's not how mining works at all. Every miner can include the same transactions in their candidate blocks, and almost all do since they all want to include the highest fee paying transactions. Candidate blocks between pools will usually contain around 98-99% of the same transactions. The reason the block is empty is as I explained in the thread linked above: When a node receives a block from somewhere else, it has to spend a little bit of time verifying that block, checking every transaction in the block is correct and accurate, and then updating its set of unconfirmed outputs to remove all the outputs which have just been spent and add all the new outputs which have just been created. This doesn't take long - usually in the order of a few seconds depending on your hardware - but it isn't instant.
While this is happening, a miner cannot create a new block filled with transactions to work on, because it doesn't know which transactions it can and cannot include until it verifies which transactions have just been mined in the block it just received. So for these few seconds, the miner's options are either to have their mining equipment sit idle and do nothing, or attempt to mine an empty block until they have fully verified the last block. Since having their equipment sit idle would be a waste of money, most miners attempt to mine an empty block for a few seconds until they create a normal block filled with transactions and then switched to trying to mine that instead. Very occasionally a miner will be successful in these few seconds and will mine an empty block. |
|
|
|
What if "the rest of the world" as you call it doesn't want the product of China with time? Doesn't make things any better for us in the US. If China are faced with trading with rest of the world or trading with a country which has defaulted on its debt and will not pay its creditors, then they have no reason to choose the latter, knowing in advance they will simply lose money. No matter what is happening to the US now, I believe they would overcome, this is not the first time they would be faced with economic and financial issues, they always bounce back greater. "Greater" is definitely subjective. The only reason we have bounced back every time is because we have increased the debt ceiling and taken on exponentially higher levels of debt. This cannot continue forever. |
|
|
|
Can someone explain to me how the following is possible: They've already said that this will use Shamir's Secret Sharing. (Let's not even get in to why SSS is a bad idea: https://blog.keys.casa/shamirs-secret-sharing-security-shortcomings.) In a 2-of-3 set up, if one share is lost you can recombine the other two shares to recreate the secret, and then from that secret generate three new shares It's not clear whether that would require the user to set up everything again from scratch, or whether Ledger would just recreate your seed phrase and then generate three new shares automatically. I'm sure I don't need to point out the massive risk with the second option. What prevents them from collaborating to steal customer funds and pretending that the user himself fucked up with recovery keys? Absolutely nothing. Why the customer paying for service is not included in this recovery quorum? Because you are too stupid to write down 24 words on a piece of paper, remember? Pay us instead and we'll definitely keep it safe. Wink wink. |
|
|
|
The basics of wallet categorization as custodial and non-custodial is the idea of who holds the private keys. And in a closed source wallet you simply don't know who holds the private keys, so you cannot call it non-custodial. |
|
|
|
Downloading, verifying transactions, and adjusting the node's mempool to purge the already confirmed transactions takes no more than 200ms In a perfect scenario, maybe, but the network is not perfect. The mining pool also has to build a candidate block, calculate the Merkle root, and then update all its miners with the new candidate block hash. If the whole process genuinely took only 200ms, then we wouldn't see empty blocks at all. But it simply is not that quick. It takes a few seconds in the real world, and so we still occasionally see empty blocks being mined. |
|
|
|
The only upside is that it requires device-based confirmation, similar to signing signatures, or at least so they claim. And yet, if they can implement a function to export your seed phrase from the secure element with a simple software update, then they can also implement a function to remove the need for any physical button presses with a simple software update. Personally, I'm moving over to Trezor. There is nothing stopping the same issue from arising on Trezor devices, and indeed, the seed phrase can already be extracted from Trezor devices by an attacker in ~15 minutes. Not to mention Trezor's partnership with blockchain analysis and government surveillance. Trezor is a poor substitute. If they can enable such a feature with the user's consent, what stops them from enabling it without the user's consent if the user doesn't want to use it? All they have now is a promise they can't do it, but their words and guarantees are worth very little at this stage. Agreed. The whole "opt in" nonsense they are touting is completely meaningless. They could choose to enable it as mandatory in a future update, or maybe even do it anyway behind the scenes, and you would never know. And during all this, Ledger devs are completely absent on social media despite their subreddit going in to meltdown, and Ledger haven't even bothered to brief their Customer Support agents on how it actually works, leading to them guessing when answering questions: https://www.reddit.com/r/ledgerwallet/comments/13j5cna/introducing_ledger_recover_answering_your/jkev3or/How not to run a company, 101. |
|
|
|
NO!
In as much as it seed phrase can be imported into another wallet in order to access the private keys and blockchain, it should be called a non-custodial wallet. The reasons that some wallets are closed source isn't arrogance and in some cases these wallets started as open source and later turned to closed source. You are wrong. Just because it provides a seed phrase does not mean it is non-custodial. Since the wallet is closed source, you have absolutely no idea how that seed phrase was generated, how it is stored, who else has access to it, and so on. For all you know, Coinbase (or Coinomi, or Trust wallet) have a list of every seed phrase their wallets have ever generated stored on a server somewhere. I'd also point out that the reasons Trust wallet gave for moving to closed source are bullshit: I know this is the reasoning Trust wallet give for being closed source, but I don't buy this reasoning at all. The only part of a wallet which 99.9% of users pay attention is the GUI. It is trivial to clone a GUI even without access to the source code. Being closed source might keep all the back end, the wallet generation process, the signing transaction processes, etc., hidden from attackers, but attackers do not care about any of that in the slightest. All they need is a wallet which looks the same as Trust wallet, which sends any generated or entered seed phrases to their server online. So they can use any bare bones code which generates seed phrases, add in their malicious code to send those seed phrases to a server, copy the GUI just by looking at it, and release it to the app store as "Trust Wallet". Being closed source does nothing to protect against this.
|
|
|
|
And still they ignore the most pressing question that everyone is asking: Why is this even possible in the first place? No answer for that question on Reddit or Twitter either. If this "feature" isn't business suicide, then their PR and current handling of the situation definitely is. How difficult is it to just come out and give some straight answers? |
|
|
|
|
Show Posts
