Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net 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 attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ 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. Brooks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
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 (https://github.com/bitcoin/bips/pull/29) 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. Brooks On Tue, Jul 15, 2014 at 8:07 AM, Eric Winer enwi...@gmail.com 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 m...@plan99.net 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 UPSILON WITH HOOK http://codepoints.net/U+03D2, COMBINING ACUTE ACCENT http://codepoints.net/U+0301, NULL http://codepoints.net/U+, DESERET CAPITAL LETTER LONG I http://codepoints.net/U+10400, PILE OF POO http://codepoints.net/U+1F4A9) - Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn - Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF - Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 - *Note:* The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of0xcf9300f0909080f09f92a9 before further processing -- Want fast and easy access to all the code in your
Re: [Bitcoin-development] Paper Currency
2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de: 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 alexy...@gmail.com 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? Brooks -- 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. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Physical key / edge detection software and PIN to generate private key
On Thu, Mar 13, 2014 at 9:38 PM, Jack Scott jack.scott.pub...@gmail.comwrote: BIP: XX 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 Abstract: 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: https://www.google.com/search?q=tracking+markerstbm=isch), 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. Brooks -- 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! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On Mar 6, 2014 3:47 AM, Mike Hearn m...@plan99.net 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. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd p...@petertodd.org 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: G / \ 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: G / \ 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: G / \ 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. Brooks -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz 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 https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. 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)? Brooks -- 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. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
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? Brooks -- 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. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP39 word list
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.
MidnightLightning
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.
slush
--
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.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
