the problem is not many people know how to check, and the meaning of open source self. Sure, we will be very comfortable if hear the application is open source, but many of them including me don't know how to check the code even shown on GitHub. I don't know what the inject code of maliciously programmed. This is true, and has been the topic of lengthy discussions on this forum regarding open and closed source wallets. At the end of the day, if you unable to review the code yourself, then unfortunately it does come down to trust. However, with a closed source project you are trusting the small team or sometimes individual developer who is maintaining the project. With an open source project, at least you know there are many independent pairs of eyes on the code. For a project as popular and widespread as Tor, you can be relatively confident that malicious code would not make its way in to the browser, or at least not without someone alerting the community and widespread outrage. |
|
|
|
I'm not sure how biased an average die is Exactly the point. If you have no idea how biased your dice are, then why would you feel comfortable using them to generate something as sensitive as a bitcoin private key or seed phrase? That's just irresponsible. Not all coins are fair either. How do you test that? Depends how certain you want to be that your coin is fair. You can never be 100% sure your coin is fair, but you can asymptotically approach 100% with increasing confidence of ruling out ever smaller biases. For example, to exclude a 55/45 bias with 99% confidence, you would need to flip the coin 664 times. However, to exclude a 51/49 bias with 99% confidence, you would need to flip the coin 16,589 times. A more practical approach would be to simply use the von Neumann approach I alluded to above. Take any coin and flip it in twice. If the first flip is heads and the second flip is tails, write down 0. If the first flip is tails and the second flip is heads, write down 1. If the two flips are both heads or both tails, don't write down anything. Repeat until you have 128 zeros or ones written down. This method completely eliminates any bias in the coin and produces a uniformly distributed output. It will require a lot less flips than any method to test whether or not your coin is actually fair. |
|
|
|
kind of like you. Well, I appreciate the vote of confidence, but I still wouldn't recommend using dice rolls to generate a seed phrase. Even ignoring everything we have discussed above about randomness extraction and hash functions, dice are more likely to be biased than coins, are more likely to be thrown in a non-random way, it would be harder and take longer to detect that bias, and the statistical methods and tests required are more complicated. To test your dice are actually fair before using them would take longer than just using coin flips in the first place, and there are many more ways you could mess up your dice rolls than a simple heads = 0 and tails = 1 with a coin. a byte is only 8 bits not 256 bits. 8 bits can have 2 8 = 256 different values. |
|
|
|
Seed phrases are not "registered" in any sense of the word. A seed phrase is used to generate private keys. It can generate a near endless number of private keys. Each private key it generates is at a unique derivation path, meaning that (unless you do something very non-standard) each private key is linked to exactly one address for one specific coin type. Now, taking bitcoin as an example - every single bitcoin address possible already exists. You can send coins to any valid bitcoin address imaginable, regardless of whether or not someone possess the private key which will allow those coins to be spent. The network has absolutely no idea if someone possesses the relevant private key, because private keys and seed phrases are not registered with the network in any way. You simply create them in private, and then use them to later sign transactions. I can create millions of seed phrases and millions of private keys in private if I like, and the network has no idea I have done so. The derivation path used to generate an address in most seed phrase using wallets is explained in BIP44. Further, SLIP44 gives you the registered coin type field number for most altcoins. Because of how this works, seed phrases generate private keys which are unique to each coin. |
|
|
|
|
So you restore a wallet which has your earlier addresses in it, but then even after generating thousands of new addresses you cannot see your more recent addresses?
The only two options here are either your original wallet had an enormous gap of unused addresses, even more than the several thousand you have already generated, or at some point you switched to a different wallet and forgot that you had done so.
Is your seed phrase generate by Electrum or is it BIP39? Are you sure you don't have any other seed phrases? Are you sure you never used a passphrase? If your seed phrase is BIP39, are you sure you didn't use it to create more than one wallet, either at a different derivation path or a different script type (legacy/segwit/etc.)?
It is also strange that Electrum could no longer find your wallet file after the error. An error with Electrum shouldn't delete your wallet file. Have you checked your wallet folder to see if your wallet file is still there and accessible? Find it at /.electrum/wallets.
|
|
|
|
So recently 50% of BSV's hashpower comes from something called "mempool.com". Most explorers have been claiming this hashpower as "unknown" but the blocks are identified. Any idea why they are mining empty blocks? Are CSW and Taal going to simply re-org all these blocks away because they don't like them? On another note, lets hope this is the first of many exchanges to start seeing BSV for the scam that it is: It appears that @WhiteBit Exchange quietly delisted BSV yesterday. For 24 hours there's no trading volume being reported anymore, the link to the public trading page is now re-routed to, oh irony, the BTC page and the Search page returns a "No results". |
|
|
|
Maybe not something better but maybe you're putting "full time cryptographers" on a bit of a pedastal. Working in the medical field, I have become acutely familiar over the last 3 years with people who have no medical training, and indeed do not even comprehend just how little they understand, making wild, entirely unsubstantiated, and often downright impossible claims. I have seen it enough, and the dangerous outcomes such a self righteous Dunning-Kruger bias produces, to be alert to recognizing it in myself. I have no formal training or education in cryptography. I don't even have any formal training or education in any of the fields which underpin cryptography, computer science, mathematics, cybersecurity, programming, etc. I know a bit about these things, sure, but I am entirely self taught and I am under no illusion that what I do know barely scratches the surface of these fields. I know enough to know that I don't know nearly enough to start making up my own ad hoc entropy generation schemes. I just don't buy the story that you need a 10 year degree to be able to do something as simple as rolling dice... Which is why I have advocated that if you want to generate your own entropy from a physical process, then to simply flip a fair coin 128/256 times (or more, using a von Neumann debiasing approach, if you can't be sure the coin is fair or you will flip it fairly), and turn that in to a seed phrase directly. Don't try to perform randomness extraction on a series of dice rolls when you've likely never even heard of that term before. |
|
|
|
That guy's words are worth the value of the text file they are typed in retrospectively hex edited in to. Fixed that for you.  |
|
|
|
Computers won't ever generate that number in a range of [1, 2^256], even if it's random, because it doesn't look random. There is exactly the same chance of it generating 827 as there is of it generating any other number. Would you feel more confident if you had the dice rolls hashed by HMAC-SHA? But HMAC requires a key and a message, which you don't have with a simple series of dice rolls. And no, I'm not suggesting we should use HMAC instead - I'm simply pointing out that there are gaps in your (and my) knowledge. When we often talk about not using closed source wallets because we can't know what they are doing, and we often talk about not coming up with your own encryption scheme for your back ups because you will almost certainly come up with something inferior or lock yourself out of your own wallets, then it doesn't make sense to advocate coming up with our own entropy generation schemes when we don't really understand the intricacies of what we are suggesting. A lot of full time cryptographers have spent a lot of time working on methods to securely generate entropy. I'm not crazy enough to think that I, with no formal cryptography training, will be able to come up with something better. |
|
|
|
When was this email written? And why is Gavin still emphasizing that CSW is the bitcoin creator? This particular email is dated "March 14, 2016 7:27 PM". Interestingly, there is an email from Gavin dated April 6, 2016, which asks for the following from the signing session: I just spent some time thinking about what I'd like to get out of the meetings tomorrow. I'll be bringing my laptop and a brand-new USB stick, I'd like to see some or all of the following copied onto it so I can verify on my laptop:
PGP-signed message with the well-known key containing tomorrow's date and the phrase "So it goes" (I'm a Kurt Vonnegut fan)
One or more messages signed using keys from early bitcoin blocks (using bitcoind signmessage/verifymessage functionality)
Never-before-published private emails or forum posts to or from me, from 2010 Of course, we now know that Gavin did not receive anything even close to any of those things. CSW includes the following in his reply: I am not the media whore I am touted to be and I am also not seeking funds.  I do not want to attend conferences. Nor do I seek affirmation. Particularly ironic given the whole hodlonaut trial is about CSW claiming that hodlonaut's tweets stopped him from attending conferences.  |
|
|
|
I refuse to accept that a random number once used as input in SHA256 gives non-cryptographically-secure result 827 is a random number. Its SHA256 output is not secure enough to use as a private key. My point is not that all SHA256 outputs are insecure, but rather you might very well generate one which is not nearly as secure as you think it is. but because experts say it. Correct me if I'm wrong, but I've never seen an expert say to feed some dice rolls to SHA256 and use the output to generate a wallet. Instead, it's a hash of the private key and the message.
Besides ECDSA signatures, the second half part of HD wallets is deterministic Both using HMAC-SHA(x), which is different from SHA(x). Is this in a manner of speaking? Who's Jim?  |
|
|
|
But the court could decide that to win on truth Holdo would have to *prove* Wright wasn't Satoshi and that he didn't achieve that. What a travesty that would be, that for some reason the burden of negative proof would be on Hodlonaut, rather than burden of proof being on CSW (one which he has spectacularly failed). If CSW's claim is the tweets defamed him because he is Satoshi, then the burden of proof should lie firmly on his shoulders to prove this is the case. Quod gratis asseritur, gratis negatur.Yes, I was thinking about this on the drive home from work today. This case could be the one
which starts the crumbling of CSW's house of lies and so could be an extremely important case. If the court rightfully find that all CSW's submitted forgeries are, well, forgeries, then it will certainly be interesting when it comes to future cases. Does he resubmit all his provably false documents? Does he come up with new forgeries instead? Does he just submit nothing at all? |
|
|
|
is it possible Brave can take the detail like the private key? It would be possible for any browser to be able to steal a private key or session token if it were maliciously programmed to do so, but given that Brave and Tor are both open source, then the chances of the necessary code making it in to the release builds is incredibly small. The risk of using Brave is not a security one, but rather a privacy one. i have tried about 3 times using TOR browser and the last one I leave about 1 hour didn't withdraw it and is still intact when put it on electrum. I have left chips on ChipMixer for months before withdrawing them, all without issue. The risk of doing so is not via a malicious browser stealing your session but rather of something happening to ChipMixer. If your browser was going to steal your session, it would do so when you access the session, meaning the period of time you leave the coins on ChipMixer is irrelevant for such an attack. |
|
|
|
|
You are the one introducing analogies which are completely missing the point.
Again, I'm not arguing that a private company cannot make rules about how you interact with that private company. Of course they can. What I'm saying is that PayPal appointing themselves the sole arbiters of truth, and fining users money that has nothing to do with PayPal is horseshit. If you have no problem with some faceless stranger seizing your assets because you said something they don't like, then again I don't really know what to say. I hear North Korea is nice this time of year? You're gonna go wild for CBDCs?
All your usual ranting about Lightning and mixers is entirely irrelevant and entirely off topic, so I will not derail this thread by debunking your nonsense for the nth +1 time.
|
|
|
|
Hard-core CLI transaction creation? I think you're right, there's not much of a market for that. I was picturing a very minimal GUI, as presumably most people who are able to navigate CLI transaction creation from scratch would also be able to read code well enough to vet a wallet like Electrum. |
|
|
|
I don't understand much from the texts you've quoted Then that alone should be enough to convince you that there is more to consider here than just inputting a string in to SHA256 and being happy that whatever it outputs is secure enough to use as your entropy source. Numbers derived from a random number are considered pseudo-random, but they're treated as equivalently cryptographically secure. What you are talking about here is randomness extraction. This is a whole field of study on its own, and is much more complex than simply "Use SHA256". Whether you represent the seed with base 2, base 6, base 10, base 16 etc., it doesn't have a difference Except that you've now introduced a modulo bias. But damn it Jim! I'm a doctor, not a cryptographer! As I say, I do not know enough about this topic to give you a full technical explanation, and that alone is enough for me to know that I shouldn't be using such methods as my own ad hoc entropy derivation scheme. Maybe someone more knowledgeable can come along and explain that just taking a SHA256 of some dice rolls is actually perfectly safe, but I doubt it, and until then I'm not willing to gamble the security of my wallets and my coins on an untested method I know I don't fully understand. |
|
|
|
An alternative way to generate entropy, is to not use the sum of the outputs as the seed, but write down the dice results (1, 2..., 6) and SHA256 the output. That way, you can have a fixed number of dice rolls. I wouldn't do this. I am by no means knowledgeable in this field, but I know enough to know that by using SHA256 as a randomness extractor like this you will almost certainly end up with much less entropy than you think you are achieving. Here are a few relevant quotes from the original HKDF paper: We end by observing that most of today’s standardized KDFs (e.g., [4, 5, 57, 40]) do not differentiate between the extract and expand phases but rather combine the two in ad-hoc ways under a single cryptographic hash function (refer to Section 8 for a description and discussion of these KDF schemes). This results in ad-hoc designs that are hard to justify with formal analysis and which tend to “abuse” the hash function, requiring it to behave in an “ideally random” way even when this is not strictly necessary in most KDF applications (these deficiencies are present even in the simple case where the source of keying material is fully random)] Efficient constructions of generic (hence randomized) statistical extractors exist such as those built on the basis of universal hash functions [15]. However, in spite of their simplicity, combinatorial and algebraic constructions present significant limitations for their practical use in generic KDF applications. For example, statistical extractors require a significant difference (called the gap) between the min-entropy m of the source and the required number m′ of extracted bits (in particular, no statistical extractor can achieve a statistical distance, on arbitrary sources, better than 2-((m-m′)/2) [60, 63]). That is, one can use statistical extractors (with its provable properties) only when the min-entropy of the source is significantly higher than the length of output. These conditions are met by some applications, e.g., when sampling a physical random number generator or when gathering entropy from sources such as system events or human typing (where higher min-entropy can be achieved by repeated sampling). In other cases, very notably when extracting randomness from computational schemes such as the Diffie-Hellman key exchange, the available gap may not be sufficient (for example, when extracting 160 bits from a DH over a 192-bit group). In addition, depending on the implementation, statistical extractors may require from several hundred bits of randomness (or salt) to as many bits of salt as the number of input bits. However, there is little hope that one could prove anything like this for regular cryptographic hash functions such as SHA; so even if the assumption is well defined for a specific hash function and a specific group (or collection of groups), validating the assumption for standard hash functions is quite hopeless. This is even worse when requiring that a family of hash functions behaves as a generic extractor (i.e., suitable for arbitrary sources) as needed in a multi-purpose KDFs. There is a lot more to securely generating entropy than just feeding what you think is a long enough, random enough string in to a SHA256 function and being happy with the output. I would stick to either /dev/urandom, or a physical process which can generate your entropy directly, such as flipping a coin. Anything beyond that introduces too many possibilities for error, many of which the average user is completely oblivious to the very existence of. As I said previously in this thread, just rolling some dice and using the output without even thinking about your min-entropy among other things (if you've even heard of these terms at all) is a recipe for disaster. |
|
|
|
the question is how and why? can i prove to myself somehow that the site is a scam? maybe that's why it never got took offline because they can't prove it 100%. I mean, it is a well known scam based on how many reports we have of people losing money on it, and reports of it generating addresses which have already been used. I suppose you could try to examine the back end (although since being sold and turning in to a scam then obviously the source code is no longer available on Github), or use it to generate some addresses to fund and watch your coins being stolen. Being a scam is rarely enough to get a site taken down altogether, though. which is why i like simple code minimal code. code that i can understand. code that isn't thousands of lines long when it doesn't need to be. The thousands of lines of extra code are to program additional functions like a GUI, coin control, being able to choose a fee, different address types, multi-sig, Lightning support, and so on. The code usually isn't there for no good reason. Perhaps there is a market for a bare bones wallet which can only generate segwit addresses, sign transactions, and nothing else, but I can't imagine it would be a very big market. |
|
|
|
There is no difference between hodling your money in your bank account or in stablecoins.
As much as I would prefer to only use bitcoin, I use a bank account and keep fiat in it. However, I have never and will never own a single dollar worth of a stablecoin. By holding a stablecoin, you are accepting all the risks of the underlying fiat (inflation, seizure, censorship, etc.), while also accepting all the additional risks of the stablecoin on top (hacks, scams, seizure, censorship, bankruptcy, etc.) You are trusting twice as many third parties for essentially no benefit. yes you may think having your skull crushed is a bit harsh for just telling the property owner that ihis wife is a fat slut.. but his house rules are his right Most countries don't allow you to murder someone for calling your wife a bad name, and if you think this is acceptable behavior, I don't really know what to say. so instead of crying about how businesses property rights might harm your use of their business.. think about setting up your own services that do not harm you or your users I have no need to set up a competitor to PayPal which is trustless and censorship resistant - we already have bitcoin. Doesn't mean I'm going to stop pointing out how terrible PayPal are. |
|
|
|
Wright does not have access to anything that Satoshi Nakamoto should have access to that is not already public This is a great quote. Perfectly sums up everything to do with CSW - a big fat nothing burger. In the interests of balance, here is the link to CSW's closing arguments: https://mylegacykit.medium.com/closing-arguments-craig-wright-1737e3531f7fI've only very briefly read through it, but they spend a lot of time essentially hand waving about legality and witnesses, without presenting any hard evidence, much like the trial itself. Very interesting that they dedicate only a single paragraph to the KPMG report (4.6.1), and don't attempt to refute or even mention the barn door evidence of forgeries, such as the checksum or Finney's bug fix. |
|
|
|
|
Show Posts
