Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Brooks Boyd
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn wrote:

 Or alternatively, fix the reasons why users would have negative
 experiences with full blocks

 It's impossible, Mark. *By definition* if Bitcoin does not have
 sufficient capacity for everyone's transactions, some users who were using
 it will be kicked out to make way for the others. Whether that happens in
 some kind of stable organised way or (as with the current code) a fairly
 chaotic way doesn't change the fundamental truth: *some users will find
 their bitcoin savings have become uneconomic to spend*.

 Here's a recent user complaint that provides a preview of coming

 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
 onto a paper wallet. When I try to send it, a window pops up stating
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.

Has there been any talk about reducing the time between blocks? If blocks
were allowed to come twice as fast, they would be able to clear pending
transactions in the mempool the same as if the block size doubled, but
would allow mining to stay more decentralized since miners wouldn't be
working on such large-scale blocks? It would still take more storage space
to store the blockchain, though.

Bitcoin-development mailing list

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-15 Thread Brooks Boyd
I was part of adding in that test vector, and I think it's a good test
vector since it is an extreme edge-case of the current definition: If the
BIP38 proposal allows any password that can be in UTF-8, NFC normalized
form, those characters cover the various edge cases (combining characters,
null character, astral range) that if your implementation doesn't handle,
then it can't really be said to be BIP38-compatible/compliant, right?

The passphrase in the test vector is NOT in NFC form; that's the point.
Whatever implementation gets designed has to assume the input is not
already NFC-normalized and needs to handle/sanitize that input before
further processing. To test your implementation for compliance, you should
not be inputting the NFC-normalized bytestring as the password input, you
should be entering the original passphrase as the test. My original pull
request for this change ( shows a
Python and a NodeJS way to input that test vector password as intended.

Some input devices may already handle the input as NFC, which is great, but
per the BIP38 proposal, that shouldn't be assumed, so various
implementations are cross-compatible. If one implementation assumes the
input is already NFC, they may encode/decode the password incorrectly, and
lock a user out of their wallet. Android allows different user keyboards to
be used, so I'm guessing there's one somewhere that allows manual entry of
unicode codepoints that could be used to enter a null character, and with
the next version of iOS, Apple devices will also get custom keyboard
options, too, so even if the default Apple keyboard does NFC-form properly,
other developers' keyboards may not. So while it is an extreme edge case,
that is not very likely to be used as a real password by any user, that's
what test vectors are for: to test for the edge case that you might not
have expected and handled in your implementation.


On Tue, Jul 15, 2014 at 8:07 AM, Eric Winer wrote:

 I don't know for sure if the test vector is correct NFC form.  But for
 what it's worth, the Pile of Poo character is pretty easily accessible on
 the iPhone and Android keyboards, and in this string it's already in NFC
 form (f09f92a9 in the test result).  I've certainly seen it in usernames
 around the internet, and wouldn't be surprised to see it in passphrases
 entered on smartphones, especially if the author of a BIP38-compatible app
 includes a (possibly ill-advised) suggestion to have your passphrase
 include special characters.

 I haven't seen the NULL character on any smartphone keyboards, though - I
 assume the iOS and Android developers had the foresight to know how much
 havoc that would wreak on systems assuming null-terminated strings.  It
 seems unlikely that NULL would be in a real-world passphrase entered by a
 sane user.

 On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn wrote:

 [+cc aaron]

 We recently added an implementation of BIP 38 (password protected private
 keys) to bitcoinj. It came to my attention that the third test vector may
 be broken. It gives a hex version of what the NFC normalised version of the
 input string should be, but this does not match the results of the Java
 unicode normaliser, and in fact I can't even get Python to print the names
 of the characters past the embedded null. I'm curious where this normalised
 version came from.

 Given that pile of poo is not a character I think any sane user would
 put into a passphrase, I question the value of this test vector. NFC form
 is intended to collapse things like umlaut control characters onto their
 prior code point, but here we're feeding the algorithm what is basically
 garbage so I'm not totally surprised that different implementations appear
 to disagree on the outcome.

 Proposed action: we remove this test vector as it does not represent any
 real world usage of the spec, or if we desperately need to verify NFC
 normalisation I suggest using a different, more realistic test string, like
 Zürich, or something written in Thai.

 Test 3:

- Passphrase ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK
- Encrypted key:
- Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
- Unencrypted private key (WIF):
- *Note:* The non-standard UTF-8 characters in this passphrase should
be NFC normalized to result in a passphrase of0xcf9300f0909080f09f92a9 
further processing

 Want fast and easy access to all the code in your 

Re: [Bitcoin-development] Paper Currency

2014-05-19 Thread Brooks Boyd
 2014-05-18 13:14 GMT+01:00 Andreas Schildbach
 One problem we couldn't figure out here though - how to protect the
 notes from unauthorized redeem. Like if someone else tries to reach your
 wallet with his own NFC - how can we distinguish between deliberate
 redeem by owner and fraudulent redeem by anybody else with custom built
 long range NFC antenna? Any ideas?

 I think you'd need multiple factors to protect against that attack. Like
 encrypting with a key that is printed on the note as an QR code.

On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko wrote:

 Yes, but it must not sacrifice usability. It's paper money, people are used 
 to it and they have rather high standard of expectations in this area. Any 
 usbility sacrifices in this area result into failure of the whole thing.

 Best regards,
 Alex Kotenko

One thought I had reading through this exchange: I think the general
public is becoming more aware of the hacker with a long range
antenna sort of attack, since credit cards are getting microchips
that can be scanned. There's a few videos I've seen of white hat
hackers demonstrating how a suitcase-sized apparatus carried by
someone walking down the street can scan and make charges on cards in
people's pockets as the attacker brushes past. Hence RFID-blocking
sleeves/wallets are on the market, such that your smart credit card
can't make a purchase while its in your wallet. Is a RFID-blocking
wallet also NFC-blocking? Irregardless of whatever future cash you
choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
its the wallet/purse that needs an upgrade, to ensure your money
doesn't spend itself while its in your pocket, but you can easily
remove it and spend it conveniently?


Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
Bitcoin-development mailing list

Re: [Bitcoin-development] Physical key / edge detection software and PIN to generate private key

2014-03-14 Thread Brooks Boyd
On Thu, Mar 13, 2014 at 9:38 PM, Jack Scott

 Title: Physical key / edge detection software and PIN to generate a
 Bitcoin private key
 Author: Jack Scott
 Status: Idea
 Type: Standard Track
 Created: 13-3-2014

 A method is proposed to generate a Bitcoin private key by using a physical
 key in conjunction with image recognition software and a PIN.  Use edge
 detection software applied to incoming video feed to convert the shape of a
 physical key into an equation that describes the key.  The hash of the
 key's equation plus a user generated five digit pin can then be used to
 create a Bitcoin private key.

Interesting idea, though as Wladimir mentioned, a real-world key is much
less secure than a Bitcoin/PGP key, though in this case, I could see your
physical/visual key being any complex, high-contrast image (like a Motion
Tracking Target:,
if just using edge-detection (a high-contrast image would help make
low-light or out-of-focus shots still able to be detected), though like a
QR-code, it should probably have calibration markers in the corners to
specify orientation (would help decoding a skewed or rotated image) and the
standard should enforce some minimum level of complexity to prevent really
simple and easy-to-reproduce/steal keys .

Though if you're getting to that level of complexity, you might as well
just have a QR code of the private key.

Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
Bitcoin-development mailing list

Re: [Bitcoin-development] Instant / contactless payments

2014-03-06 Thread Brooks Boyd
On Mar 6, 2014 3:47 AM, Mike Hearn wrote:

 I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some notes on what's involved.

 3) Have some kind of decentralised reputation network. I spent some time
thinking about this, but it rapidly became very complicated and feels like
an entirely separate project that should stand alone from Bitcoin itself.
Perhaps rather than try to make a global system, social data could be
exchanged (using some fancy privacy preserving protocols?) so if your
friends have decided to trust seller X, your phone automatically trusts
them too.

A reputation network might be an interesting idea, or several different
networks with different curators (to prevent complete centralization), like
how the US credit score system has three main companies who track your
score. Something like a GPG ring of trust, with addresses signing other
addresses would work well, if some sort of Stealth address or HD wallet
root was the identity gaining the reputation, then address re-use wouldn't
have to be mandatory.
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
Bitcoin-development mailing list

Re: [Bitcoin-development] Instant / contactless payments

2014-03-06 Thread Brooks Boyd
On Thu, Mar 6, 2014 at 12:12 PM, Mike Hearn wrote:

 If there was a way for a Bitcoin user to provide feedback on a payment
 (ECDSA signature from one of the addresses involved in the payment, signing
 an identifier of the payment and a feedback score)

 Well now you're getting into the area that I said rapidly got very

 Define bitcoin user? What stops me paying myself to accrue positive
 reputation? Etc.

Yes, I could see how that could get hairy; it would also need some ability
to rate those giving the feedback, such that if you generate a whole bunch
of payments to yourself, those payees don't have reputation on their own,
so their review of you as a payer isn't weighted that highly. Then you have
that ring-of-trust possibility where Alice thinks Eve is bad, so the fact
that Eve thinks Bob is good doesn't impact Alice. But if Carol thinks Eve
is good, Carol thinks Bob is good too, so Bob's reputation is different
based on who's asking, and it's the responsibility of the individual
members to maintain their own good/bad user lists. Would you think that's a
good thing or a bad thing to give the individual players that level of
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
Bitcoin-development mailing list

Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support

2014-02-05 Thread Brooks Boyd
On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd wrote:

 On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
  Because it's trivial to create collisions! You can choose exactly what
  output you want. That's why XOR is a very bad digest scheme.

 You're close, but not quite.

 So, imagine you have a merkle tree, and you're trying to timestamp some
 data at the bottom of the tree. Now you can successfully timestamp the
 top digest in the Bitcoin blockchain right, and be sure that digest
 existed before some time. But what about the digests at the bottom of
 the tree? What can an attacker do exactly to make a fake timestamp if
 the tree is using XOR rather than a proper hash function?

Given a tree like:

 / \
E   F
   / \
  C   D
 / \
A   B

Where G is the root hash and A is the legitimate data that was included in
the tree, the legitimate user provides B, D and F along with A to prove A
is part of the tree G.

Now an attacker could just make up an arbitrary set of values that XOR
together into G, like:

 / \
Z   Y

And could therefore claim Z is part of tree G by providing Y. But if A is
also trying to prove its a part of G, we know the first level of the tree
must be E and F. It cannot also be Z and Y, so one of the two users is
lying and the deceit is obvious, though not obvious which user is lying.

An attacker could look more convincing by using the data passed with A as a
starting point:

   / \
  E   F
 / \
/   \
   / \
  C   D
 / \ / \
A   B   Z   Y

Instead of working off of G, work of the lowest branch provided by A in its
verification (D, in this case), and create the fake data Z, and calculate Y
such that Z XOR Y == D (which is just Z XOR D). Now the attacker can claim
Z is part of G by supplying Y, C, and F. The tree looks valid (it can
coexist with the proof provided by A, at least until someone else claims to
be a descendant of the D node as well), and since G was verified by
timestamp, looks like Z existed before that timestamp, when really it could
be added at any time by calculating Z XOR D.

Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
Bitcoin-development mailing list

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Brooks Boyd
On Mon, Jan 20, 2014 at 11:42 AM, slush wrote:

 Hi all,

 during recent months we've reconsidered all comments which we received
 from the community about our BIP39 proposal and we tried to meet all
 requirements for such standard. Specifically the proposal now doesn't
 require any specific wordlist, so every client can use its very own list of
 preferred words. Generated mnemonic can be then applied to any other
 BIP39-compatible client. Please follow current draft at

So, because the [mnemonic]-[bip32 root] is just hashing, you've
effectively made your mnemonic sentence into a brainwallet? Since every
mnemonic sentence can now lead to a bip32 root, and only the client that
created the mnemonic can verify the mnemonic passes its checksum (assuming
all clients use different wordlists, the only client that can help you if
you fat-finger the sentence is the client that created it)?

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
Bitcoin-development mailing list

Re: [Bitcoin-development] Tor / SPV

2014-01-15 Thread Brooks Boyd

 My goal here is not necessarily to hide P2P nodes - we still need lots of
 clearnet P2P nodes for the forseeable future no matter what. Rather we're
 just using hidden services as a way to get authentication and encryption.
 Actually the 6-hop hidden service circuits are overkill for this
 application, a 3-hop circuit would work just as well for most nodes that
 aren't Tor-exclusive.

Ah, I see, so you're intending to use the Tor hidden services not for their
original purpose (hiding), but rather as as authentication (someone may
spoof my clearnet IP, but only I have the private key that makes this Tor
hidden service connect to me, so you can trust when you connect to it it's
really me). So if you trust the clearnet IP to be a friendly node, that
makes a more secure connection, but if you're already talking to a bad
node, moving the communication to Tor doesn't change that. I agree the
six-hop circuits would be overkill for that; I wonder if the network
slowdown you get on Tor will be worth the increased security? Yes, you'll
be more protected from MITM, but if this is widely adopted, would the
overall transactions/second the Bitcoin network could handle go down?

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
Bitcoin-development mailing list

Re: [Bitcoin-development] BIP39 word list

2013-11-01 Thread Brooks Boyd
I was inspired to join the mailing list to comment on some of these
discussions about BIP39, which I think will have great use in the Bitcoin
community and outside it as a way to transcribe binary data.

The one thought I had as the discussions about similar characters are
resulting in culling words from the list, is that it only helps to validate
input, not help the user if it is incorrect.

For example, if both cat and eat were in the word list, and someone
wrote down eat, but later mis-translated it and put cat back into
translator, the result would be a checksum error; cat is a different
number, so the checksum would fail.

As it currently stands, cat would not be a valid word (eat is the real
word, and no other number is cat), so the translator can throw a
different error which is more helpful (i.e. 'cat' isn't a valid word
choice), but still doesn't get the user to the proper translation.

What about if the wordlist included those words that are so similar to
each other that we only kept one of them and had them all refer to the
same number? I propose the wordlist have the possibility of multiple words
on a single line, with the first word on the line being the primary or
real word to be used, with the other similar words be included so that a
translation program if it wanted to assist the user could fix their input
for them (verbosely or not), along the lines of 'cat' isn't a valid word
choice; assuming you meant 'eat', which is valid. You might still hit a
checksum error if that similar word is still the wrong word, but as it
stands now, I know you culled a bunch of words from the wordlist as too
similar, but if I want to try and help the user fix a bad input, I need to
write a translation program with a full english dictionary alongside the
BIP39 dictionary.

I'd be willing to create a pull request for such an update, but before I
delve into that, does this sound like a good idea? I could see it devolving
into a slippery slope if every number in the 2048 set had a dozen word
variations (misspellings, similar words, slang terms for the real word,
etc.) which could get confusing of how similar is similar enough to be
added as an alternate, and the standard would need to be clear that when
translating binary to words, you only use the main word for that row, not
any of the variations.


 I've just pushed updated wordlist which is filtered to similar characters
taken from this matrix.
 BIP39 now consider following character pairs as similar:
 similar = (
 ('a', 'c'), ('a', 'e'), ('a', 'o'),
 ('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
 ('c', 'e'), ('c', 'g'), ('c', 'n'), ('c', 'o'), ('c', 'q'),
('c', 'u'),
 ('d', 'g'), ('d', 'h'), ('d', 'o'), ('d', 'p'), ('d', 'q'),
 ('e', 'f'), ('e', 'o'),
 ('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
 ('g', 'j'), ('g', 'o'), ('g', 'p'), ('g', 'q'), ('g', 'y'),
 ('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
 ('i', 'j'), ('i', 'l'), ('i', 't'), ('i', 'y'),
 ('j', 'l'), ('j', 'p'), ('j', 'q'), ('j', 'y'),
 ('k', 'x'),
 ('l', 't'),
 ('m', 'n'), ('m', 'w'),
 ('n', 'u'), ('n', 'z'),
 ('o', 'p'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
 ('p', 'q'), ('p', 'r'),
 ('q', 'y'),
 ('s', 'z'),
 ('u', 'v'), ('u', 'w'), ('u', 'y'),
 ('v', 'w'), ('v', 'y')
 Feel free to review and comment current wordlist, but I think we're
slowly moving forward final list.
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Bitcoin-development mailing list