hmm, ok - thanks for the replies so far. Makes sense. Nothing is especially safe in this game, I suppose! Although, I guess I am more worried about my Nano and its seeds than I used to be about cold storage keys, tbh.
“Nothing is especially safe”!? You had better be worried about being killed by a flying fire hydrant than about bruteforce of Bitcoin’s cryptographic keys. It has happened at least once somewhere that a man was killed by a flying fire hydrant. Bruteforce of the type of crypto used in Bitcoin has never happened, and never will. (More to the point, be worried about your computer’s security, theft, etc. Bruteforcing of keys does not happen. Stealing of keys happens oft. But if you use hardware wallets and cold storage, you are already better protected than most people.) |
|
|
|
For example, if someone had half of a key would they be able to derive the other half at a better-than-brute-force rate? Or is every character independent of every other, I guess I am asking. Each bit is indeed independent of the others. (Keys are made of bits, not characters.) But that’s not the point: If an attacker has half the key, then at worst from his perspective, he only needs to bruteforce half a key. By analogy: Imagine you have a combination lock which has a combination of 77 independent digits numbered 0–9. (77 digits, because a 256-bit key has about 1.16×10 77 possible values.) Now, an attacker has 39 of the digits of the combination. The attacker can simply set those 39 digits, and work on the other 38. The foregoing discussion considers only considers bruteforce attacks. |
|
|
|
Whilst wading through an old thread of morbidly fascinating stupidity-train wreckage about “brainwallets”, I discovered that tinhyeumaunang uid #937704 (then Brand New; now Member) had the utter gall to copypaste a forum moderator’s post in its entirety— 2 minutes, 14 seconds after registering that account:It is highly NOT RECOMMENDED to use brainwallets. Humans are a horrendously low source of entropy. There are multiple research papers and programs that show that brainwallets are horribly insecure and easily cracked as what you think is a strong password probably is not a strong password.
BIP 38 paper wallets will not be particularly helpful here. It only protects against someone stealing your paper wallet and trying to get the keys. BIP 38 does not protect against someone just guessing the password you used to create your brainwallet.
Copypaste ( archived.is, archive.org): It is highly NOT RECOMMENDED to use brainwallets. Humans are a horrendously low source of entropy.
There are multiple research papers and programs that show that brainwallets are horribly insecure and easily cracked as what you think is a strong password probably is not a strong password.
BIP 38 paper wallets will not be particularly helpful here.
It only protects against someone stealing your paper wallet and trying to get the keys. BIP 38 does not protect against someone just guessing the password you used to create your brainwallet.
Current stats: Name: tinhyeumaunang Posts: 114 Activity: 114 Position: Member Date Registered: January 03, 2017, 10:42:50 AMLast Active: September 17, 2017, 04:56:08 PM I hope that I have here caused the nuking of an bad account which would have value on the account-sale market.
Are you looking to become a moderator yourself in the future? That’s bait; but I’ll bite, because I think you misunderstand the glory of being a moderator. My reporting stats currently say this: “You have reported 139 posts with 100% accuracy”. That is since I started actively engaging the forum on 1 December 2017 (though I did about 70 of those in one hours-long binge). So yes, sometimes I get in the mood to help out and clean up some of the trash around here. But I would be not be jumping for joy at the prospect of making a commitment to take responsibility day in, day out for a task tantamount to emptying a landfill with a spoon—as the garbage trucks keep rolling in. A rotten, thankless task, which elicits replies such as yours hereinabove: “ Why don't you stop and think for a moment... What the fuck... ...lest we get caught by some nut [C’est moi!]...” I see mods get that guff all the time. Not that I think they give a damn about such opinions, and neither do I; but also, I so rarely see them receive a simple “thank you” for efforts without which the forum would be totally useless. Now, this discussion has gone way off-topic in a quite useful thread; thus unless something pertinent or at least interesting be said by you in reply, I will not reply to you further. P.S.: Thanks, mods. |
|
|
|
Preface Brainwallet fans, I’ll tell you what: Why don’t you generate a 12-word BIP 39 mnemonic representing a piddling 128 bits off /dev/urandom, then “secure” it with a BIP 39 passphrase consisting of the very mostest unguessablist sentence your oh so creative mind can imagine. You will feel better; and yet despite your own desire for foot-shooting, you will be secured by 128 bits of entropy. Sound fair? On second thought, no. Don’t do what I just said. If you are so stupid as to use a “brainwallet”, then others deserve that money more than you do. My sincere advice is to use the brainwallet.
curiosity81, it seems (at a glance) that you are deploying a word generator generated from a decent ( i.e. non-human) source of randomness. Not a syntactically valid phrase, not something the user comes up with, not something from a book you cross your fingers and hope to be really obscure. Not what most people call a “brainwallet”. That raises an obvious question, which I must ask out of—curiosity: Why don’t you simply use BIP 39? It was developed by the same experts whose security acumen you trust when you use Bitcoin anyway. Its wordlists were developed with human use in mind, e.g., all words on the English wordlist are unique within the first four characters. And it will perfectly encode 128–256 bits of randomness in 12–24 words, without any of the pitfalls of trying to develop your own word randomization scheme. With your wordlist, I presume not tuned to a power of 2, did you avoid the common mistake of introducing modulo bias? (I did not review your code.) Does your wordlist exclude similar, confusable words? (I am guessing not.) Etc. In that context, this: I would prefer a system which follows the KISS-principle (KISS = Keep It Simple Stupid) for long term archiving: Firstly, the code should reproducible easily. I am not sure, if the bash is perfect for this. But I like it, since most algorithms are already developed by experts and available on a standard linux system. They only have to be plugged together. Secondly, code should be easy to understand (which might be a little bit contradictory with respect to bash-syntax). (In my case, comments are still missing in some scripts in the moment. And code is not uniformly yet with respect to mathematical computations.) But it should be possible to print out the scripts and the linux version used and archive it in a bookcase or similar. Much better would it be if it can be carved in stone or glas.
...makes it irresistable for me to plug my own utility (red highlight added): I have released an initial version of the easyseed(1) utility for secure generation of BIP 39 mnemonic seed phrases. As any worthwhile software, it comes replete with a manpage, q.v. It generates mnemonic phrases in these languages and writing systems: - Chinese (Simplified) (汉语)
- Chinese (Traditional) (漢語)
- English [default]
- French (Français)
- Italian (Italiano)
- Japanese (日本語)
- Korean (한국어)
- Spanish (Español)
My original motivation for writing this was that I needed a lightweight, reliable BIP 39 seed phrase generator with easily auditable sources and minimal dependencies for use on a stripped-down airgap machine. The source code is short, easy to read, and lovingly commented; it can be readily understood by anybody with a basic knowledge of the C programming language. Its only dependencies are cc(1), make(1), and a library SHA256 implementation—available on most platforms via libcrypto or otherwise. It’s admittedly growing a little bit more complex—with much of the complexity being in self-testing code. However, I have a priority to keep it auditable and avoid external dependencies. I still need to add the seed output, which per BIP 39 requires normalization of phrases to Unicode NFKD; no, I will not link ICU! I’m working on a solution to that.
Quick comments on a skim down the thread: seriously, I am not aware of any hacking tool, or even a serious theoretical paper, that would successfully address a problem of brute forcing original sentences made by a human brain. make an original sentence (one that you can't just google) of ~20 words and I am betting all my bitcoins that no man armed with the fastest computer is going to brute force it before we both die.
if I wanted to crack brain wallets, I'd rather put my effort in finding a way to calculate the EC-private key from the EC-public, rather than try to brute force a creativity (or insanity) of a human brain. the first one not only seems less complex and more straight forward to me, but (most of all) it would then crack all the wallets :)
C Human phrases are in fact recognized and accepted as bad idea. Time to break these phrases is the proof not opinion
Sorry. You're obviously not going to change your dogmatic rhetoric, whilst I am not interested in debating non science on this forum. (And more posts like this.) piotr_n, you have no idea what you’re talking about. A human-made natural language phrase is a horrible, stupid idea. I don’t care how creative you claim to be, or how much you bluster about how amazingly scientific you are (versus all the people who know more than you about this subject). You are giving bad advice which will get somebody hurt; and from how you’re talking, it’s evident that you will then turn around and say they didn’t do it right, like you could. How very kind of you.
You'll likely have to use a combination of different hashes in varying rounds (eg., 10x Sha256 => 2x Scrypt => Bcrypt => etc) requiring an attacker to reproduce your exact hashing steps. Let's not forget that anyone who is scanning for brainwallets has a lot of time to do so and thus can account for multiple hashing rounds as well.
Question being, whether a simple obfuscation algorithm that can be done in your head or with a piece of paper is sufficient, as opposed to a computer-supported one. Unless you can mentally sha256 :P
Given the amount of possible simple obfuscation algorithms I guess one can achieve sufficient security without computer support, assuming you don't rely on any well known methods (rot13 anyone?). In other words, this could be a use case where rolling your own "crypto" and security by obscurity might be a good thing.
Using the word “algorithm” loosely, if you can’t design an algorithm which remains secure when your adversary knows it, then you will certainly be unable to design an algorithm which is secure when “unknown”. Note the subtle difference from what you usually hear. |
|
|
|
3) For certain kinds of problems, QC can provide quadratic speedup, which is a massive speedup. For symmetric ciphers, this probably just means you double your key size - where 128 bits of security used to be sufficient, now you need 256. No big deal. The real problem is with public-key encryption. But lay-people often forget that the quantum speedup blade cuts both ways. We can build encryption systems which take advantage of quantum speedup and make quantum cryptanalysis of PKE quadratically more difficult, mooting the theoretical advantage that cryptanalysts get from quantum speedup. In fact, this is why Bitcoin uses the public-key hash instead of the public-key itself and recommends against address-reuse; in the event of working, at-scale QC, your coins are still secured behind 128-bit-equivalent security as long as you don't reuse addresses or publish the public-keys for your addresses. ... I'm sorry to short your message but I would know at the underlined sentence if I have good understood the point. The fact that Public Key and Bitcoin Address are different is not a safeguard against Quantum computing, because when you sign a transaction you are revealing on the blockchain your Publickey, so that Adress can be exposed to QC attack, is that correct? My doubt is when you speak about "address-reuse": what do you mean with that? I have a cold storage paper wallet ecrypted via BIP0038 where I periodically put some cash into that. I've never spent BTC on that but there is not a single but multiple input transactions, so there are multiple utxo transactions on the blockchain. Until I don't spend bitcoin is it still secured or not? Should I use a cold storage paper wallet for every transaction? Thanks in advance In this particular context (but see below), “address reuse” means reuse of an address from which you have spent. Transactions to your address contain the public keys of whoever sent you the money—not your public key. But the only information revealed in the blockchain when you receive money is the Hash160 (RIPEMD160 of SHA256) of your public key. That is what haltingprobability referred to as the “public-key hash” in the portion you underlined. (For the sake of simplicity, I here assume only P2PKH and P2WPKH addresses. What do these stand for? “Pay To (Witness) Public Key Hash”.) But this discussion misses the point that the security of public keys is just fine. It seems that you missed this upthread: There are excellent reasons to avoid address reuse; but this is not one of them. I say this as a paranoid security nut: The security of publicly disclosed public keys is just fine. That is why they are called public keys. The only exception I would here make is if you have coins which you intend to potentially leave in cold storage for decades. Then, yes, you will want the extra security margin of the key being unpublished. Bingo. Do you intend to leave the coins in cold storage for decades? If so, then I recommend that you do what you said you’re doing: Use the addresses for receiving only. Not that I expect for secp256k1 to be broken: If storing something for decades (or longer), I prefer some extra security margin “just in case”. Otherwise, there is no reason to worry about revealing the public key. secp256k1 is secure. You may rely on it. But there is another, very different reason to avoid reuse of addresses for both sending and receiving: Privacy. Blockchain analysis is already easy enough for experts. Address reuse of all kinds makes it trivial. To start with, for a bare modicum of privacy, use one HD wallet with the seed and keys generated (and backed up!) on an airgapped computer; and from that wallet, use a different address every time you receive money. This recommendation has nothing to do with the security of your money against attacks on public keys. |
|
|
|
A newbie’s first post (uid #1563170; preserved evidence) copypasted verbatim from The Register: As far as defeating hashcash goes, the numbers are daunting for quantum computer designers: by 2028, the researchers reckon, you'd need a 4.4 million qubit machine to achieve 13.8 gigahashes per second: “This is more than one thousand times slower than off the shelf ASIC devices which achieve hash rates of 14TH/s”.
Shor's algorithm, a quantum algorithm for factoring integers (that's how it would attack cryptography), is a better path, they write.
Deploying a quantum computer against the secp256k1 elliptic curve Bitcoin uses is much more dangerous: if the signature is cracked, the scheme is completely insecure, and attackers can plant fake transactions and steal Bitcoin.
As with cracking the proof-of-work, the researchers assume quantum computers get big and fast relatively quickly, and even so, they fall slightly short: with a 10 GHz clock rate, around half a million qubits, and a low enough error rate of 10-1 could crack the signature in 30 minutes.
That's close enough to make Bitcoin's critical 10-minute rate “highly insecure”, so the authors recommend the Bitcoin protocol be migrated to a post-quantum signature scheme.
Copypaster didn’t even bother to fix the “10 -1”. Of course, this was in a totally irrelevant thread (“Re: Brainwallet history”).
Hey, guys, don't you think you are a bit overdoing this?
Why don't you stop and think for a moment that there are only 26 letters (well, that depends on the alphabet you are using) and these are the same letters we all use. What the fuck, we even use the same words and phrases or even whole sentences now and then ("insult to the injury", yeah). These are idioms as well as golden thoughts said by wise people which allow you to express your idea without delving into pesky details. Should we avoid using them lest we get caught by some nut and reported to a mod?
deisik, you quoted my post in its entirety; but you failed to even read it. Here, let me help you: Both these posts were... consecutive in the same thread[.]
[...]
Yes, those posts are here quoted in their entireties.
Contra your implication, it is not as if I trawled the forum for two people who by happenstance uttered similar short sentences years apart amidst thoughtful discussion. I think mods made the right call, nuking both users. |
|
|
|
To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers. Here is the address of Wikileaks ( http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems: | English | real element glow tennis pluck museum hair shuffle | | Chinese (Simplified) | 洁 爱 唱 仰 泪 吴 乎 怒 | | Chinese (Traditional) | 潔 愛 唱 仰 淚 吳 乎 怒 | | French | parole distance fautif sombre notoire loyal flairer ratisser | | Italian | retina erba idillio suonare potassio opposto india scuderia | | Japanese | にもつ けろけろ しちりん ほめる とかす たんまつ しゃうん はんしゃ | | Korean | 잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반 | | Spanish | pie dulce gimnasio tabla oscuro molde guerra repetir |
What's the purpose of this feature? It seems (superficially) that there's no real-world use case. Why, what’s the real-world use case of BIP 39? To ease human memorization, transcription, and communication of pseudorandom strings! Bitcoin has been a leading innovator in the development of better ways for humans to interact with cryptographic gibberish. With BIP 39 mnemonics, a mere mortal human can memorize a pseudorandom string, write it into a sealed Last Will and Testament in a manner easy to transcribe back into a computer—or if necessary, whisper it into somebody’s ear... I should think that people may want to memorize, transcribe, speak, or whisper .onion addresses, too. As an English speaker, which would you prefer to deal with in your capacity as not being carved out of silicon: “wlupld3ptjvsgwqw” (ouch!), or “ real element glow tennis pluck museum hair shuffle”? Chinese people may prefer “潔 愛 唱 仰 淚 吳 乎 怒”. For overlapping reasons, I have also been working on the application of BIP 173 Bech32 encoding for .onion address data ( more). That has the advantage of error correction, and a more compact format; different tools apply to distinct use cases. Again, Bitcoin technical innovation opens new possibilities in other applications of cryptography. I am also using these methods with PGP. I’ve seen PGP mnemonics before, of course—but the mnemonic standard I recollect having seen many years ago used a 256-word (8-bit) alphabet, rather than the 2048-word (11-bit) alphabets from BIP 39. Thus, unnecessarily long word strings. I am also working on a spec for what I call Bech32 “PGP Descriptors” to encode key fingerprint plus metadata. See those ugly hexadecimal strings in my signature? Bitcoin will provide a better way. Meanwhile, for use in Bitcoin, I have almost completed full BIP 39 implementation in easyseed(1). It would have been done yesterday; but for the missing final piece, generation of the output seed, I need means to perform the specified Unicode NFKD normalization without dragging in ugly dependencies. The rest is trivial. |
|
|
|
Edit: Mods completely nuked both these users as I was typing this post, which prophetically concludes: “Mods, please beat me to it!” Props to the mods here.
What adds insult to the injury of copypasting, is copypasting nonsense. Both these posts were deleted by mods almost instantly after I reported them. They were consecutive in the same thread ( which itself seems spammish). Please consider some bans here. uid #1367288 “quynhanh9c” (here the one copied) mostly/only makes one-liner nonsense posts. uid #1433133 “lamsersanjay” (here the copier) seems similar—and copypastes nonsense, which should be doubly nuke-account-on-sight. Take the time to observe and observe everything
Take the time to observe and observe everything bitoin
Yes, those posts are here quoted in their entireties. I think I will be now be reporting a bunch of posts by these users. Mods, please beat me to it! |
|
|
|
Edit: 404 from Github apparently resolved by support. It appears that you can access my repositories now; please tell me if you have any problems. Sorry about that. Sometimes our spam-detecting systems miss the mark and you were accidentally flagged in the process. I've gone ahead and removed the flag and you shouldn't see that message again.
I’ve requested further info, in hope that I could avoid this happening ever again. I will edit or post with further info, if and as appropriate. Regardless—if things are indeed working now, I apologize to the forum for the noise. You may well understand how I reacted when I saw my public source code repositories suddenly go 404. Aside, n.b. that I habitually PGP-sign my commits using the ECC key with fingerprint 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.
Notice: The Github repositories for easyseed(1) and bech32(1) have suddenly gone 404. Little remains of me on Github but for my open pull request to the BIP repository ( archive.org, archive.is). I saw that, before I saw this: Here is the message I sent to Github support via their web form after I saw the latter: -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Immediately upon sending my last support message, whereby I requested
support with my profile and projects being 404, I received for the first
time the following message:
Image SHA-256:
4be910e882cd68b62bf1390c608f8407070e43a9d5c4f040e31a8a2e56e2df6d github_flagged_nym-zone.png
Quote:
>Your account has been flagged.
>Because of that, your profile is hidden from the public. If you believe
>this is a mistake, contact support to have your account status reviewed.
This was on the same page as displayed the following message:
>Thanks for getting in touch with us!
>We’ll get back to you shortly.
I did *not* see the flagged notice before. I also have not received
any other notification, by e-mail or otherwise.
Obviously, I must request that you review and undo this forthwith.
I must also inquire as to the ostensible grounds for this action.
There is *no* legitimate reason for my account to be “flagged”.
For the record:
- All the code I have published to the Github account “nym-zone”
was either written by me, or used under an open-source license.
- I have not engaged in any abusive behaviour.
- I have done nothing wrong.
- I have absolutely no idea what this is about. Nobody has even
complained to me; and Github did not give me the courtesy of so much
as an e-mail to advise that I’d been suddenly 404ed. I was lucky to
have caught this when I did; and I am blindsided here.
This message is signed with the PGP key I have registered in my
Github account, and have used to sign my commits. Its fingerprint is
0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.
~ Signed, ~
nullius@nym.zone
2018-01-02
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWksc4wAKCRDEJ5MVn575
SY3NAQC3otsvONLOxDI/C20CqKUFzy9WH+SkQOewA/aqAq/mVQD/cNQxKcHjyhhO
GRajS4PH+Gy1PstnoZ5JalIfIZJI3gM=
=BDZi
-----END PGP SIGNATURE-----
The text of my prior message, which I had saved before sending (that’s my habit on the forum, too!): And just when I’d been contemplating my next improvements and little projects.... Persons interested in my code are invited to contact me directly, via e-mail (preferred) or PM. However this resolves, I will also must needs seek more reliable means of publishing my source code.
|
|
|
|
Edit: 404 from Github apparently resolved by support. It appears that you can access my repositories now; please tell me if you have any problems. Sorry about that. Sometimes our spam-detecting systems miss the mark and you were accidentally flagged in the process. I've gone ahead and removed the flag and you shouldn't see that message again.
I’ve requested further info, in hope that I could avoid this happening ever again. I will edit or post with further info, if and as appropriate. Regardless—if things are indeed working now, I apologize to the forum for the noise. You may well understand how I reacted when I saw my public source code repositories suddenly go 404. Aside, n.b. that I habitually PGP-sign my commits using the ECC key with fingerprint 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.
Notice: The Github repositories for easyseed(1) and bech32(1) have suddenly gone 404. Little remains of me on Github but for my open pull request to the BIP repository ( archive.org, archive.is). I saw that, before I saw this: Here is the message I sent to Github support via their web form after I saw the latter: -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Immediately upon sending my last support message, whereby I requested
support with my profile and projects being 404, I received for the first
time the following message:
Image SHA-256:
4be910e882cd68b62bf1390c608f8407070e43a9d5c4f040e31a8a2e56e2df6d github_flagged_nym-zone.png
Quote:
>Your account has been flagged.
>Because of that, your profile is hidden from the public. If you believe
>this is a mistake, contact support to have your account status reviewed.
This was on the same page as displayed the following message:
>Thanks for getting in touch with us!
>We’ll get back to you shortly.
I did *not* see the flagged notice before. I also have not received
any other notification, by e-mail or otherwise.
Obviously, I must request that you review and undo this forthwith.
I must also inquire as to the ostensible grounds for this action.
There is *no* legitimate reason for my account to be “flagged”.
For the record:
- All the code I have published to the Github account “nym-zone”
was either written by me, or used under an open-source license.
- I have not engaged in any abusive behaviour.
- I have done nothing wrong.
- I have absolutely no idea what this is about. Nobody has even
complained to me; and Github did not give me the courtesy of so much
as an e-mail to advise that I’d been suddenly 404ed. I was lucky to
have caught this when I did; and I am blindsided here.
This message is signed with the PGP key I have registered in my
Github account, and have used to sign my commits. Its fingerprint is
0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.
~ Signed, ~
nullius@nym.zone
2018-01-02
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWksc4wAKCRDEJ5MVn575
SY3NAQC3otsvONLOxDI/C20CqKUFzy9WH+SkQOewA/aqAq/mVQD/cNQxKcHjyhhO
GRajS4PH+Gy1PstnoZ5JalIfIZJI3gM=
=BDZi
-----END PGP SIGNATURE-----
The text of my prior message, which I had saved before sending (that’s my habit on the forum, too!): And just when I’d been contemplating my next improvements and little projects.... Persons interested in my code are invited to contact me directly, via e-mail (preferred) or PM. However this resolves, I will also must needs seek more reliable means of publishing my source code.
|
|
|
|
I was wondering if we worship Satoshi like a God if we'd be tax exempt. It couldn't hurt. All hail the one true God, Satoshi Nakamoto!
The god of Bitcoin has no need of religious pretensions for tax purposes. O, ye of little faith! The Nullian Bitcult is for zealots who believe that Bitcoin shall make banks, fiat currencies, and taxes obsolete. |
|
|
|
The bitcoin code base / protocol was complete years ago and needed no other genius proof of dev any more like E=mc^2 does not need to be bubbled up by other fellows any more.
And thus, you show your ignorance of physics, too. E=mc^2 is the equation for the rest energy of matter. Got velocity? A more complicated equation is required to ascertain E. [...] Sure, go learn more physics but the genuis part is done by Einstein and yet we are years later and still try to prove parts. Dont come up with all the rest here or could you solve the rest with pure men power (as you do now with btc + SW + ...) ? Satoshi did the genius part (by introducing artificial order = energy = negativ entropy) and there is no need to extend it with extra kinetics.. and dilute the genius order. Think big and accept that BCH will work better also because its simpler. Oh, my. Somebody “learned” from “science popularizers”, then combined that miseducation with a heaping dose of New Age woo. “artificial order = energy = negativ entropy”? “extra kinetics”? With all the quack pseudoscience pseudo-jargon flying about, next we will hear that quantum mechanics proves we have entered the Age of Aquarius. Quantum mechanics also proves that I have psychic powers; and my psychic powers tell me that you are an imbecile.
Every time I feel I need a short break, I pop in here and see if this thread was updated with more stupidity. If so, I take a swing at one of Ver’s hapless little drones. That takes less effort than hitting a punching bag; and it’s more satisfying than shooting literal fish in a barrel.
Gosh, I just don't know. I've never tried to shoot literal fish in a barrel. Adjusting aim for refraction is not a problem. How about big fish, little barrel? Try a shotgun. Sawed-off. Nah, still not as fun as smacking down bcash shills and sycophants. Which itself is not so rewarding as the spiritual solace brought by founding my own cult, ϐ bitcult.faith ϐ. All hail the god of Bitcoin.
Sure, go learn more physics but the genuis part is done by Einstein and yet we are years later and still try to prove parts. Dont come up with all the rest here or could you solve the rest with pure men power (as you do now with btc + SW + ...) ?
Satoshi did the genius part (by introducing artificial order = energy = negativ entropy) and there is no need to extend it with extra kinetics.. and dilute the genius order.
Think big and accept that BCH will work better also because its simpler.
Huh?  Why shouldn't we make transaction malleability avoidable and then make use of the powers of bitcoin script that Satoshi had designed? Using opcodes that Satoshi conceived but didn't personally use is too complicated? Taras, per the above, you are arguing with somebody who just proved that negativ [sic] entropy brought us into the Age of Aquarius! Humble yourself. Don’t you dare presume to question the wisdom of a guru. |
|
|
|
I wish to reply further (also to cellard’s last post above); for now, simply to address one issue: Regarding address formats. I'm seeing a lot of engineering-level discussion but better would be to simply toss samples at test groups and have them type them in, gather comments and so forth.
They did. Did you read what gmaxwell said upthread? Red highlights are here added. Bech32 is designed for human use and basically nothing else [...]
In actual testing transfering bech32 addresses to another person is on the order of 5x faster with bech32 due to errors being made even in careful usage of base58-- more than the time itself transferring a base58 address is often insanely frustrating-- you read it, and ... nope, no idea where it's wrong, only that it's wrong -then you try reading the whole thing again and again and again.
[...]
Mature software will tell you _exactly_ where such errors are located, especially if they involve a charset mistake, but even errors beyond that. There should be very little hunt and peck with BECH32, and in my experience there isn't any at all.
that I hate it, I can’t handle it—I find it absurdly frustrating and error-prone. This is what many people report, and even people that said they didn't mind it handled it much more slowly. My general experience from when we stared on this was that people who said mixed case wasn't an issue changed their mind after actually trying to convey an address view spoken word or writing it down by hand with pencil and paper. ... Either they had never done it before or had done it infrequently enough that they'd already repressed the traumatic memories. I don't doubt that there are some odd people out there which never have any trouble with it, but I haven't encountered anyone yet who doesn't when actually tested on it. [...] 1. My regards to Pieter Wuille and Greg Maxwell: I can tell that an excruciatingly detailed thought process about Bitcoin address formats went into that bit of engineering. Somebody stayed up in the dark wee hours, pondering the philosophy of Bitcoin address formats. Somebody aspired to consummate perfection in the art of Bitcoin address formats. Well, you are probably also “odd”. Coming from me, take that as a compliment.
Thanks, including a lot of testing with both people and machines, several CPU decades went into the design of the error correcting code... and in fact the techniques even required to be able to measure their performance are themselves novel and probably publishable innovations. Not to mention extensive review and redesign with many other similarly crazy people. We understood that introducing a new address format is a big step that can't be done often, and thought it would be appropriate and acceptable to really work hard on it. IIUC, the “CPU decades” must have crunched alphabets with the NIST visual similarity data referenced in BIP 173 and the error-correcting code to find the alphabet which, per available data, would have the lowest statistical likelihood of undetected or unrecoverable bit errors. (gmaxwell, am I correct in this inference?) Those data were originally gathered from humans; and the resulting address format was tested with humans. It is a rule in UI/UX design that you never ask people what they subjectively prefer, because they don’t actually know what works better for them. Instead, you test performance. How long does an average user take to transcribe an address in a particular format? How many errors are made on average? These are objective measures. According to the foregoing, all discussed upthread, this was done with Bech32.
P.S., try playing around with Bech32. It’s really an awesome format for pseudorandom bitstrings. I’m currently trying to apply it elsewhere, too. |
|
|
|
easyseed(1) now has support for multiple languages.To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers. Here is the address of Wikileaks ( http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems: | English | real element glow tennis pluck museum hair shuffle | | Chinese (Simplified) | 洁 爱 唱 仰 泪 吴 乎 怒 | | Chinese (Traditional) | 潔 愛 唱 仰 淚 吳 乎 怒 | | French | parole distance fautif sombre notoire loyal flairer ratisser | | Italian | retina erba idillio suonare potassio opposto india scuderia | | Japanese | にもつ けろけろ しちりん ほめる とかす たんまつ しゃうん はんしゃ | | Korean | 잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반 | | Spanish | pie dulce gimnasio tabla oscuro molde guerra repetir |
|
|
|
|
public static money MaxFee=1.50 // Less miners because not enough cream to go around
[...] public static money MaxPorschePrice=1.50 // Less Porsches because not enough cream to go around That should work, right?
[...] Block sizes are not relevant to this issue.
I know. Really, that’s my point. Per the ridiculous thread title, Lightning Network will compete with Visa. It is not comparable to “Bitcoin Cash”, “S2X”, or genital herpes. The amount of WRONG, it hurts.... Do what I’m doing! I’ve been ignoring my forum duties (so rudely as to fine folks) whilst coding multilanguage support for easyseed(1). The race has been on to get that feature published before midnight UTC; and I appear to be losing. The latest push was yet another battery of runtime integrity self-tests. I think by now I have more lines of runtime test code than feature implementation code, which is good for a utility which pertains to Other People’s Money. Every time I feel I need a short break, I pop in here and see if this thread was updated with more stupidity. If so, I take a swing at one of Ver’s hapless little drones. That takes less effort than hitting a punching bag; and it’s more satisfying than shooting literal fish in a barrel. Now, I’m happy to have chatted with you irrelevantly on a thread which is anyway offtopic garbage in its entirety. Cheers! |
|
|
|
Said “Anti-Cen” with unspecified units, presumably some fiat currency with no possibility of Byzantine agreement on an exchange rate: public static money MaxFee=1.50 // Less miners because not enough cream to go around
That is one of the stupidest ideas I have ever seen in my whole life; and it has plenty of competition between the four corners of this world. You have no idea how Bitcoin works. Or how reality works. The security level of Bitcoin’s Byzantine agreement on transaction ordering grows proportionally to its value, as mining increases in revenue, and thus becomes more competitive. But it’s not even necessary to look that far. Capping the sole criterion which miners use to choose between transactions of equal size, and users use to determine which transactions are important to them, is tantamount to trying to fulfill my desire for a Porsche with one simple line of code: public static money MaxPorschePrice=1.50 // Less Porsches because not enough cream to go around That should work, right?
Look at the numbers cellard posted! Do you have a home PC with 32GB spare RAM to dedicate to a Bitcoin node? Can your home connection pass 99.2GB of daily traffic? That’s all with full 8MB blocks; and according to Bitfury, all that hardware buys you a whopping 28tps. It’s still 2 orders of magnitude under the throughput of Paypal, and 3–4 orders of magnitude under that of Visa.
To compete on a practical basis with Visa cannot mean that every node has the entire transactional volume passing through it. To compete with 1/100 the volume of Visa cannot mean that every node has the entire transactional volume passing through it. Block sizes are not relevant to this issue. I know. Really, that’s my point. Per the ridiculous thread title, Lightning Network will compete with Visa. It is not comparable to “Bitcoin Cash”, “S2X”, or genital herpes. |
|
|
|
The bitcoin code base / protocol was complete years ago and needed no other genius proof of dev any more like E=mc^2 does not need to be bubbled up by other fellows any more.
And thus, you show your ignorance of physics, too. E=mc^2 is the equation for the rest energy of matter. Got velocity? A more complicated equation is required to ascertain E. What else would I expect from somebody with the abject technical incompetence requisite for belief in a linear scaling solution to an exponential scaling problem? Even a five-year-old can understand the difference between “big” and “huge”. I’m sorry that the universe is not oversimplified to fit your childish expectations. No, wait—I am not sorry, after all. Well, if ( if) BCH ever gets sufficiently popular for its 8MB blocks to persistently fill, enjoy your skyrocketing fees and backed-up mempool on your centralized pseudocoin with 1/1000 the tx throughput of Visa—as Lightning scales up to compete with the big boys.
People like Roger Ver is brainwashing new individuals like you into thinking that lightning network = centralization. It's their own altcoin which is = centralization since miners have the power to control the block sizes in their bcash crap coin.
Ver accuses others of his own worst sins. When enforced through repetition, that’s an effective propaganda technique for corralling the weak and the stupid. But BCH’s supporters even admit to their anti-node/miner-supremacy agenda; what they want is not decentralization, but “decentraliztion enough [ sic]”: BCH: mining nodes = full nodes
If 'the world' is mining this is decentraliztion enough.
Non - mining nodes are not needed for small hodlers.
Get it or stay on BTC.
|
|
|
|
BCH: mining nodes = full nodes
So, in BCH: Jihan = full nodes. Got it. If 'the world' is mining this is decentraliztion enough.
In what world are you living, that “‘the world’ is mining”? Non - mining nodes are not needed for small hodlers.
It is self-evident, you have no idea how Bitcoin works. Get it or stay on BTC.
There is only one Bitcoin; and yes, I will stay on that. |
|
|
|
I like this idea you have.
Personally I am a believer in the entropic properties of dice.
Thanks. I also like dice, especially via hardcoded output from a fair die roll of 4. But after you have already gathered some random numbers, consider this food for thought: If you’ve somehow managed to generate one secure 256-bit key then from that key you can derive all the ‘random’ numbers you’ll ever need for every cryptographic protocol... (If you haven’t managed to generate one secure 256-bit key then you have much bigger problems.) On the same principle, any kind of seed system and/or HD wallet will use a KDF to derive your actual private keys, anyway. So if your kernel’s PRNG (or your dice) gathers at least 256 bits of “real” randomness, then think of it as if it runs that through a KDF to give you the seed which you will run through a KDF to generate your keys. That is more or less what happens. On the other hand, if you really like the idea of hardware randomness, then you may be interested in Turbid. It generates high-entropy symbols using electrical noise ( not acoustical noise) caused by thermodynamic processes in the analogue electronics of an ordinary computer sound card. It still uses a hash to process its input. As far as I can see, its main advantage is that it keeps no state; but then, if you can’t trust your computer to keep secret the state of your PRNG, then how can you trust it for whatever crypto you are doing with the output of your True Random Number Generator? (Side note: If you use dice, I hope that you know how to extract binary random numbers without the “modulo bias” which unthinking people tend to suffer in such situations. Or that you have hexadecimal dice.) Also your comments lead me to point out a serious flaw in the use of off line web pages.
Namely, shouldn't such a web page (a computer program) not operate unless it was off line?
But why would you trust a web page to verify that it was offline? If you could trust it with that, then you could trust it to operate while you are online, also. Part of why I wrote easyseed was to have code which can be easily read and compiled offline. Then, you only need to worry about your compiler. See, “On Trusting Trust”. |
|
|
|
... We already have studies that show at what rate nodes would get wiped out at current block size and in increases of 2MB up to 8MB. This study was developed by Bitfury:  So if BCash was getting used AND spammed as BTC does, blocks would get filled and 95% of current nodes would get wiped out of the system. What does it mean "wiped out of the system?" Is that computed as a side effect of the fact that people don't have, say for example, another 200 gb to dedicate to block chain for each year that passes? Look at the numbers cellard posted! Do you have a home PC with 32GB spare RAM to dedicate to a Bitcoin node? Can your home connection pass 99.2GB of daily traffic? That’s all with full 8MB blocks; and according to Bitfury, all that hardware buys you a whopping 28tps. It’s still 2 orders of magnitude under the throughput of Paypal, and 3–4 orders of magnitude under that of Visa. I don’t see any figures here on iops; but I can guess qualitatively. Got RAIDed enterprise-class SSDs? Disk space is the smallest problem with big blocks. Nodes of modest means can prune. But the above table shows that there would be nothing to prune: They wouldn’t be able to keep up with the network, or even run without getting hit by the OOM-killer. (For comparison, the Steem documentation specifies a minimum requirement of 32GB RAM for a Steem node. Most users simply use steemit.com. So decentralized. But it has the magic word, “blockchain”.) |
|
|
|
|
Show Posts
