Bitcoin Forum
October 22, 2018, 06:51:18 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 ... 239 »
261  Bitcoin / Development & Technical Discussion / Re: Increasing blocksize dynamically w/economic safeguards - the ideal compromise? on: January 09, 2017, 12:14:38 PM
101 = vote increase 1.35%, pay 10% of transaction fees to next block
111 = vote increase 2.7%, pay 25% of transaction fees to next block
There are no mandated fees in the Bitcoin protocol so the natural response to schemes like this is for miners to simply accept fees via other means (such as the direct txout method supported by eligius since 2011, or via outputs with empty scriptpubkeys, or via out of band fees) and give users a discount for using them. The expected result would be fees migrating out of the fee area, and protocols that depend on them (like your suggestion) becoming dysfunctional.  Sad

I previously tried to rescue this class of proposal by having the  change not be to fees but by modifying the lowness of the required hash (effective difficulty), but it's difficult to do that in the presence of subsidy.

Unrelated, as you note your proposal is no constraint if miners agree-- this is also why it fails to address the conflict of interest between miners (really mining pools), who are paid to include transactions, and everyone else-- who experiences them as an externalize except to the extent that they contribute to economic growth (not at all a necessity: e.g. many companies want to use the bitcoin blockchain without using the Bitcoin currency at all).  Still, better to solve one issue even if all can't be solved.

262  Bitcoin / Development & Technical Discussion / Re: secp256k1 library and Intel cpu on: January 09, 2017, 11:50:01 AM
I am also interested in a faster secp256k1.

Unfortunately, it seems Pieter Wuille et al. were neither serious about providing a fast secp256k1 nor about documenting it well.  Roll Eyes

Can you show another library for the same application within a factor of _five_ of the performance?  Or with more than 1/5th the documentation?

I'm just ... beside myself at your comment, it's not even insulting: it's just too absurd.

- which alone made the LBC generator about 10% faster overall -
and later also changing the field_5x52 code in secp256k1_fe_set_b32 to
Thanks,  that function is not performance critical in anything the library was intended for ... e.g. not brainwallet cracking. But making it faster would be fine.

You might have noticed that the constant unpacking macro does effectively the same thing: but a word at a time.

If you open a PR on the function you should add it to the bench_internal benchmarks as you go.

Is there any place where R&D discussion about further development is ongoing? Before I'd start re-implementing that mess from scratch I'd prefer to participate in some "official endeavor".

same place it's always been

However, I have little hope that will make sense:
Signature verification isn't really the limiting factor in Bitcoin Core performance anymore in any case.
... just because something isn't a limiting factor isn't a reason to improve it.

Together with other statements from gmaxwell @ github ("this is alpha/, don't expect other doc shan source.." - something like that from memory) I see there seems not much motivation in further development from the "official side".
Disinterest in spoon feeding people who sound like wanna-be thieves who thefts would scare ordinary people away from Bitcoin and whom can't even be bothered to RTFM (there has been fairly detailed documentation for the library for years) is not evidence of a lack of interest in further development.

Any optimizations are very welcome - I'm sure sipa (the original author) would agree. He's a very nice guy and it's easy to contact him directly (probably best via IRC). Although, about the code used by the core,  he'll probably tell you that it's being maintained by other people now.
Uh, what?

In 5x52 asm I found 2-3% by simply doing what the cpu scheduler should be doing and issuing together the adds + muls (the cpu integer unit typically has one add and one mul unit and ideally we want to be using them at the same time).
Awesome! PRs welcome!

One question I have regarding secp256k1 is whether endomorphism is safe, and if yes, shouldn't it be enabled in bitcoin builds if it's faster (benchmarks show that it is)?
It is potentially patent encumbered for another couple years, restricting it to experimental use.

So the adcq+mulq are issued together to the mul and add units of the cpu respectively. I'm baffled on why the cpu scheduler wasn't already doing this but then again I do have an older cpu (core2 quad / 45nm) to play with - it might not be an issue with modern ones.
Generally newer cpus work better, but the performance is also more important on older (and in-order cpus like the atoms) since they're slower to begin with.
263  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: January 09, 2017, 11:27:40 AM
0.13.1 was basically only segwit.
264  Bitcoin / Development & Technical Discussion / Re: secp256k1 library and Intel cpu on: January 06, 2017, 11:36:11 AM
I thought signature verification was the biggest limiting factor in IBD process (obviously with slow CPU). 
On arm, which doesn't yet use the libsecp256k1 assembly optimizations by default-- perhaps.  Otherwise, no, not since libsecp256k1 made signature validation many times faster. Maybe on some really unbalanced system with a slow single core cpu and huge dbcache and fast network and SSD it might be a majority.
265  Bitcoin / Development & Technical Discussion / Re: secp256k1 library and Intel cpu on: January 06, 2017, 09:41:44 AM
The content in your first link would likely not be helpful.

The content in your second link-- the  would be beneficial, though potentially not by much because the dependency chain in the arithmetic is hand constructed to reduce conflicts.  If someone would like to try them out, it shouldn't be very hard.

In the context of Bitcoin development (thus achows' response), Signature verification isn't really the limiting factor in Bitcoin Core performance anymore in any case.
266  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 04, 2017, 11:23:33 PM
Is this really the case? and how do you "correctly use" Electrum seeds? because you made a "if used correctly" remark.
Coming up with the string on your own rather than having the software do it or storing it only in your memory.
267  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: January 04, 2017, 11:22:13 PM
If we aren't continually filling blocks then that is a disaster.
268  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 03, 2017, 07:27:01 PM
question the technical aspects of what I'm saying, instead of trying to undermine my motives.  It's just pathetic, man. How old are you?

Because the mod is a type of person that prefers to run a forum for kids who he can impress and patronise all the time.


By this logic nobody should trust your expertise on cryptography because you know too much about the topic and your advice might be luring unconscious  people into using solutions that you claim are secured,  but personally know how to break.

How are you going to answer that?

Ask me again if you ever see me advocating solutions which are have resulted in lots of funds loss in practice... or selling wallet cracking tools.
269  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 03, 2017, 07:24:22 PM
I have learned recently that brainwallets are not a good idea, mostly because I lurk the bitcoin reddit and I think I saw you posting about it.

Now my fear/question is: are Electrum seeds also compromised? In theory isn't it the same as brainwallets? It creates a seed and this seed contains everything. I think the new HD wallet in bitcoin core is not like that (you can't "spawn" everything with a single seed) but with electrum it seems the same idea to me than brainwallets and now im worried... (im not a coder or anything so I dont understand the details, it just seems the same to me in practice)

The two main problems problems with brainwallets is that (1) humans created the randomness and humans are surprisingly bad at that (and, worse, can't tell how bad they are) and (2) they depend on human memory to perfectly remember a long highly random string.  Human memory is not very good at this either.

Electrum seeds, used correctly, don't have either of these problems.
270  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 03, 2017, 06:55:38 PM
I think it's amusing that the two people in this thread loudly trumpeting brainwallets are someone who says they have a fetish for cracking passwords and someone who has posted extensively about wallet cracking and tried to sell scam wallet cracking tools.

This fits right in with the fact that person who popularized the idea and created was cracking these kinds of keys and complaining about how few he was finding online before creating the site.

Food for thought.
271  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.13.2 Released on: January 03, 2017, 09:06:08 AM
0.13.2 is out and here is the release announcement:

Hash: SHA512

Bitcoin Core version 0.13.2 is now available from:


Or by bittorrent:


This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:


To receive security and update notifications, please subscribe to:



Microsoft ended support for Windows XP on [April 8th, 2014](,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

- From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Change to wallet handling of mempool rejection
- -----------------------------------------------

When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error.  The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).

0.13.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- - #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
- - #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell)

### RPC and other APIs
- - #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery)
- - #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english)
- - #9122 `f82c81b` fix getnettotals RPC description about timemillis (visvirial)
- - #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
- - #9194 `f26dab7` Add option to return non-segwit serialization via rpc (instagibbs)
- - #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke)
- - #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa)
- - #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke)

### Block and transaction handling
- - #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz)
- - #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm target of 1 block (morcos)
- - #9196 `0c09d9f` Send tip change notification from invalidateblock (ryanofsky)

### P2P protocol and network code
- - #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing (TheBlueMatt)
- - #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj)
- - #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa)
- - #9058 `286e548` Fixes for test timeouts on travis (#8842) (ryanofsky)
- - #8865 `4c71fc4` Decouple peer-processing-logic from block-connection-logic (TheBlueMatt)
- - #9117 `6fe3981` net: don't send feefilter messages before the version handshake is complete (theuni)
- - #9188 `ca1fd75` Make orphan parent fetching ask for witnesses (gmaxwell)
- - #9052 `3a3bcbf` Use RelevantServices instead of node_network in AttemptToEvict (gmaxwell)
- - #9048 `9460771` [0.13 backport #9026] Fix handling of invalid compact blocks (sdaftuar)
- - #9357 `03b6f62` [0.13 backport #9352] Attempt reconstruction from all compact block announcements (sdaftuar)
- - #9189 `b96a8f7` Always add default_witness_commitment with GBT client support (sipa)
- - #9253 `28d0f22` Fix calculation of number of bound sockets to use (TheBlueMatt)
- - #9199 `da5a16b` Always drop the least preferred HB peer when adding a new one (gmaxwell)

### Build system
- - #9169 `d1b4da9` build: fix qt5.7 build under macOS (theuni)
- - #9326 `a0f7ece` Update for OpenSSL 1.1 API (gmaxwell)
- - #9224 `396c405` Prevent FD_SETSIZE error building on OpenBSD (ivdsangen)

### GUI
- - #8972 `6f86b53` Make warnings label selectable (jonasschnelli) (MarcoFalke)
- - #9185 `6d70a73` Fix coincontrol sort issue (jonasschnelli)
- - #9094 `5f3a12c` Use correct conversion function for boost::path datadir (laanwj)
- - #8908 `4a974b2` Update bitcoin-qt.desktop (s-matthew-english)
- - #9190 `dc46b10` Plug many memory leaks (laanwj)

### Wallet
- - #9290 `35174a0` Make RelayWalletTransaction attempt to AcceptToMemoryPool (gmaxwell)
- - #9295 `43bcfca` Bugfix: Fundrawtransaction: don't terminate when keypool is empty (jonasschnelli)
- - #9302 `f5d606e` Return txid even if ATMP fails for new transaction (sipa)
- - #9262 `fe39f26` Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)

### Tests and QA
- - #9159 `eca9b46` Wait for specific block announcement in p2p-compactblocks (ryanofsky)
- - #9186 `dccdc3a` Fix use-after-free in scheduler tests (laanwj)
- - #9168 `3107280` Add assert_raises_message to check specific error message (mrbandrews)
- - #9191 `29435db` 0.13.2 Backports (MarcoFalke)
- - #9077 `1d4c884` Increase wallet-dump RPC timeout (ryanofsky)
- - #9098 `ecd7db5` Handle zombies and cluttered tmpdirs (MarcoFalke)
- - #8927 `387ec9d` Add script tests for FindAndDelete in pre-segwit and segwit scripts (jl2012)
- - #9200 `eebc699` bench: Fix subtle counting issue when rescaling iteration count (laanwj)

### Miscellaneous
- - #8838 `094848b` Calculate size and weight of block correctly in CreateNewBlock() (jnewbery)
- - #8920 `40169dc` Set minimum required Boost to 1.47.0 (fanquake)
- - #9251 `a710a43` Improvement of documentation of command line parameter 'whitelist' (wodry)
- - #8932 `106da69` Allow bitcoin-tx to create v2 transactions (btcdrak)
- - #8929 `12428b4` add software-properties-common (sigwo)
- - #9120 `08d1c90` bug: Missed one "return false" in recent refactoring in #9067 (UdjinM6)
- - #9067 `f85ee01` Fix exit codes (UdjinM6)
- - #9340 `fb987b3` [0.13] Update secp256k1 subtree (MarcoFalke)
- - #9229 `b172377` Remove calls to getaddrinfo_a (TheBlueMatt)


Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - BtcDrak
- - Cory Fields
- - fanquake
- - Gregory Maxwell
- - Gregory Sanders
- - instagibbs
- - Ivo van der Sangen
- - jnewbery
- - Johnson Lau
- - Jonas Schnelli
- - Luke Dashjr
- - maiiz
- - MarcoFalke
- - Masahiko Hyuga
- - Matt Corallo
- - matthias
- - mrbandrews
- - Pavel Janík
- - Pieter Wuille
- - randy-waterhouse
- - Russell Yanofsky
- - S. Matthew English
- - Steven
- - Suhas Daftuar
- - UdjinM6
- - Wladimir J. van der Laan
- - wodry

As well as everyone that helped translating on [Transifex](

Version: GnuPG v1

272  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 31, 2016, 09:54:11 PM
Just because 95% of the blocks that the miners produce doesn't mean that non-mining Bitcoin related companies and other Bitcoin users support SegWit (Note: ready to implement != support).
Well no one is forced to implement it; so ready to implement does suggest a small amount of support at least. FWIW, before segwit's activation was set in Bitcoin Core I reached out directly to most of the non-mining Bitcoin related companies that I could fine to specifically prompt for opposition. I received back many positive responses, none opposed, and the only negative comment was from a party that hoped activation would take longer so they would have more time to add support-- it's still possible that they don't support it,  apparently not enough to send a respond saying so. After that there was a public discussion on the bitcoin-development list and the only party that argued against it was Tom Zander.

Technically speaking, the threshold is 50.694% (or potentially less depending on luck) for activation as the miners who support SegWit could decide to ignore blocks that lack a signal of support for SegWit.
Yep, only just over half is strictly needed if they're willing to orphan the other almost-half.
273  Bitcoin / Development & Technical Discussion / Re: Some magic? on: December 28, 2016, 10:59:27 PM
Arubi doesn't have a bitcointalk account, and saw others being blamed for their transaction and asked me to post this:

mw1vkYok3eGrccuMx5Ztbj3RH6Pyrb8b8z H5Fm9/Ejebxv5KybIf+hUgGcubVp3B6bxcl7RVMLUS7EABFn75VsV+S+sNW5Oc02M/awPv8tHAeIS+PJtU5qVyA= "I am not amaclin :) :  -  arubi"
274  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 28, 2016, 05:40:35 AM
Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?
So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

Not all-- we've increased it over time in response to prior instability and as we all learned better the implications.  BIP30 just used a 'past this time' decree. BIP16 was based on 55% and just used a time for the actual activation, and resulted in months of low levels of orphaned blocks being produced.  Satoshi used several hard cut softforks that were just triggered on blockheights.  BIP34 was the first to use 95% but it actually started enforcing the rules for a subset of blocks at 75%.

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  But we saw no reason to lower the criteria:  basically when it activates the 95% will have to be willing to potentially orphan the blocks of the 5% that remain if they happen to mine invalid blocks.   If there is some reason when the users of Bitcoin would rather have it activate at 90%  (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

So basically setting the criteria high protects the stability of the network in the common case, but never ties anyone's hands against something not activating. By default the safest thing happens, but no one can exploit this in an attack.

Because of this, the trade-offs favor a high threshold.
275  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:27:06 PM
But then you come back to the problem of choosing the secure password, don't you?
Which brings you back to the point that you need to learn about choosing secure passwords.
Ah ha, but no-- the requirements for the password security are much lower.

With a brainwallet, the moment you use it everyone in the world can begin cracking it-- in parallel with all other keys they are cracking at no extra cost.  They can also apply precomputed rainbow tables to try may of the passwords they tested in the past against it-- at low cost. They also can see the bounty attached to it.

If a wallet is encrypted it has a salt and (hopefully) an expensive KDF. The attacker cannot attack multiple files in parallel. If the whole wallet is encrypted, they don't know what their payoff will be and most importantly they can't even begin cracking until they get the file.  The security becomes multi-factor: You must have the file and the passphrase.  Theft of the file may also be noticed, giving you time to react.

So if your passphrase is a little weaker than you intended it to be-- there is likely no great harm.

276  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:18:04 PM
Sorry, I didn't mean that they cannot be seized by any type of government.
Mine isn't running a torture camp in Guantanamo - applying a hammer to my head would be illegal where I live.
Plus then I'd most definitely forget it Smiley
Hand, not head, for that reason! Smiley  (also, hitting people in the head tends to make them unconscious and then they can't answer. Hitting them in the hand is very painful but leaves them able to talk.)

Especially if you're not worried about torture-- use encryption! it also resists seizure in just the same way-- but: it works like a salted password hash stored privately. O(N*M) work to try N passwords for M people, and to even start you must steal a copy of the private data which you have hopefully not posted in a public database. Tongue  If you want to generate it securely and _also_ attempt to memorize it, sure knock yourself out, an extra backup doesn't hurt.
277  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:09:10 PM
Also nobody is talking about the advantages of (strong) brain wallets, that are actually making them more secure than PRNG based wallets.

Besides of the two I mentioned already:
- They don't rely on anyone's (publicly known) implementation of the "entropy"
Unless you never intend to sign a message they do... and they also depend on a human's easily predictable production of "entropy".

There are hundreds of millions of dollars worth of Bitcoin secured by the CSPRNG setup in Bitcoin Core. It is peer reviewed by quite a few subject matter experts. That is a pretty strong bit of auditing there, ... can you say the same for your scheme?

- They don't require backups
Human memory is very fallible.  We often just don't remember what we don't remember so we don't often realize how bad it is.   A fever, blow to the head, or other illness can easily kill single memories even of things you used frequently-- a brain wallet is the hardest kind to remember: to be secure it must be unusually random, and you should not be using it frequently (if you use it frequently, you will end up leaking it somehow) and being almost right is not good enough!

Backups are also easy if you don't need to redo them. They are practically free:  A small USB stick costs a few dollars, paper costs cents. You can make many backups and secure them with a weak password that your family also knows and really can never be forgotten-- but attackers with a FPGA farm in china cannot crack your password protected backed up wallet!

There is more:
- They cannot be seized
Equally true of a pasword protected backup wallet.  And both can be seized after finding evidence of you using them in the blockchain or on your computer and then liberally applying a hammer to your non-dominant hand.

- They don't need to be carried
Yes, this is perhaps the one advantage-- if you are a refugee who can literally carry _nothing_ without severe risk of losing it. But even there you would be much better off with a few backups of that key securely hidden back at home in case you do forget it and do someday find yourself in a place where you can pick it up.

- Their existence can be denied
- Even if someone can prove that a brain wallet had existed at some point in time, he's still unable to prove that you have not forgotten the password
Both equally true for an encrypted non-brainwallet.

You see, in my opinion, the biggest enemy of the brain wallets should be the government.
Brainwallets are irrelevant to the government-- they don't add any protection from the a government except in the refugee case, but they are the friend of the coin thieves -- no surprise considering they were invented by one.

You seem to have ignored my point that a brainwallet is equivalent to storing an unsalted password hash in a public database. Do you consider that incompetent security?
278  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 11:59:10 AM
The advice would be to have a computer generate it randomly.  (the next best advice is to choose it with dice but it takes so many rolls to even get 128 bits, that I have found that users don't actually comply with the procedure; a treatment that the patient will not follow is not a good treatment, no matter how perfect it is if used flawlessly). Studying the result in practice isn't politics, it's science.  Developers are not magically anointed with an ability to not make these errors, they appear to be even more vulnerable: to quick to enamor themselves with fancy schemes but just as unable to really comprehend billions of attempts per second as any other human. It isn't a question of being stupid, I do not think I can securely use a brainwallet and I do not think I am stupid.
279  Bitcoin / Development & Technical Discussion / Re: block reward that can never be spent on: December 27, 2016, 11:55:54 AM
This article claims that the block immediately following every halving can never be spent.
(I knew that only genesis block reward cannot be spent)

Is that true?
No, it's not true.
280  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!) on: December 27, 2016, 11:25:23 AM
Brainwallets were literally invented by someone who was out to rip people off; no joke!

piotr_n: Errors like you talk about are what happen sometimes when technical experts given all the time in the world work on secure entropy.  What do you think will happen when you ask less technical end users to take care of it for themselves?

Predictable failure, that is what results. And, of course, if your crypto code is broken-- your security is toast anyways: your signatures will give away your key.

People _massively_ overestimate their ability to choose unguessable strings. They come up with absurd munging schemes that are easily predicted and exploited by attackers.  The result is that brainwallets cause funds loss _constantly_.

Why is it when it turns out that some website was using an unsalted hashing scheme to store their users password hashes in a private database people pull out the torches about how incompetent the web developer is-- but when people construct brainwallet software which stores the users hashed password in a PUBLIC database-- unsalted-- where every found password results in an irreversable theft of Bitcoin, some people fall over themselves to recommend it?

... because that is exactly what a brainwallet is doing:  A public key is a hash of the private key (with special homomorphic properties that makes it useful for signatures). When you use a brainwallet you are computing an unsalted password hash and sticking it in a public database along with the amount you can steal by cracking it.  Because they are unsalted, an attacker can target N users with ~O(1) effort just like any other unsalted password hash.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 ... 239 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!