Brooks Boyd [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-11-01 to 2015-06-19
💬 Posted a total of 13 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:38:39

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/6f2397c3/attachment.html>

2023-06-07 15:23:50

- reply

📅 Original date posted:2014-07-15
📝 Original message: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 <enwiner at 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 <mike at 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\u0000\U00010400\U0001F4A9; GREEK
>> UPSILON WITH HOOK <http://codepoints.net/U+03D2>, COMBINING ACUTE
>> ACCENT <http://codepoints.net/U+0301>, NULL
>> <http://codepoints.net/U+0000>, 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 enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140715/298353e5/attachment.html>

2023-06-07 15:21:34

- reply

📅 Original date posted:2014-05-19
📝 Original message:>> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach <andreas at 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 <alexykot at 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

2023-06-07 15:15:43

- reply

📅 Original date posted:2014-03-14
📝 Original message:On Thu, Mar 13, 2014 at 9:38 PM, Jack Scott <jack.scott.public at gmail.com>wrote:
> 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+markers&tbm=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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140314/8a14c327/attachment.html>

2023-06-07 15:14:53

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Thu, Mar 6, 2014 at 12:12 PM, Mike Hearn <mike at plan99.net> 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
> complicated".
>
> 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
control/responsibility?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/be0073a8/attachment.html>

2023-06-07 15:14:52

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Thu, Mar 6, 2014 at 11:07 AM, Mike Hearn <mike at plan99.net> wrote:
> 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.
>>
> The identity would be the X.520 name in the signing cert that signed the
> payment request. It doesn't have to be a difficult to obtain cert. It could
> even be self signed for this use case, but then you lose the security
> benefits and a key rotation would delete your reputation, so in practice I
> think most people would want the reputation to accrue to the name itself.
>
That makes sense, to have self-signed certificates as a basic start, but
then is it possible to have a Bitcoin user (address) add reputation/sign
such a certificate, rather than having a central signing authority? 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) such that any user can add
to the reputation with just the Bitcoin infrastructure, without having to
learn X.500 certificate signing on top of EC signatures? If there was a
standard structure for a message to be EC-signed with your Bitcoin client,
and then a distributed store of those signed messages, could that form a
reputation score?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/3f35eb4a/attachment.html>

2023-06-07 15:14:52

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/566df540/attachment.html>

2023-06-07 15:13:01

- reply

📅 Original date posted:2014-02-05
📝 Original message:On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd <pete at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140205/25eaf6b2/attachment.html>

2023-06-07 15:12:22

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Mon, Jan 20, 2014 at 11:42 AM, slush <slush at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/6d9774f0/attachment.html>

2023-06-07 15:12:09

- reply

📅 Original date posted:2014-01-16
📝 Original message:>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/89df0023/attachment.html>

2023-06-07 15:12:08

- reply

📅 Original date posted:2014-01-15
📝 Original message:>
> 2) Secondly, we bump the protocol version, add a service flag and
> introduce a new P2P protocol command “tor?”. If a client sends a tor?
> message to a node that has the new service flag set, it will respond with a
> new “tor” message that contains a regular addr packet, with a single
> address, the IPv6-ified version of its hidden service name.
>
Rather than a separate message type that implies binding a clearnet IP to a
hidden service ID, why not add the service flag that the peer would like
Tor addresses, and the remote peer can then add IPv6-ified hidden service
addresses to "addr" messages? May need to modify the network address format
to include the ability to differentiate IPv6 clearnet vs. Tor addresses,
but then you remove the implication that a node has to give both public and
private IPs to a peer. If it's part of a batch of "addr"s, it could be my
own hidden service ID, but it could also be one that I learned from someone
else and is now propagating, for anyone to bootstrap with Tor hidden
service peers if they'd like.
Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/2f39ea14/attachment.html>

2023-06-07 15:08:23

- reply

📅 Original date posted:2013-11-02
📝 Original message:That would be a way to go, though iterating through all possibilities of a
similar letter misspell would take significantly more processing (4x3x3
= 36 total possibilities, only to cull it back to 2, in your example), than
iterating through a list of pre-calculated possibilities. It's definitely
not a hard computation on any modern device, though, and depending on how
"helpful" the program wants to try to be, it could even try help with
misspellings due to hitting a keyboard key next to the correct one or
hitting a letter twice, depending on how big a comparison matrix it wants
to create.
I do agree it should not be required for clients implementing the BIP to
help fix mis-translations, though keeping the similar letter unit test in
there I like, since it helps convey the thought that went into culling some
words from the dictionary. Though to Allen's point, what did happen with
the words that were found to be similar; was one of the similar words left
in the list or were all the similar words removed?
Brooks
MidnightLightning
On Fri, Nov 1, 2013 at 7:04 PM, slush <slush at centrum.cz> wrote:
> Hi Brooks,
>
> I've been already thinking about eat -> cat typing mistake. Actually there
> may be simplier solution than having wordlist with duplicated words.
> Because there's already a mapping of similar characters in the source code
> (currently only in unit test, but it can be moved), when user type a word
> which isn't in wordlist, application may try to use such mapping to find a
> combination which actually is in the mapping. This may be disambiguous in
> some cases, but giving a choice between few words may be better than hard
> fail. And it is actually quite easy to implement. Although I think
> application can do such smart suggestions and help user to recover badly
> written mnemonic, I don't think it is necessary to standardize such method
> directly into BIP. It may or may not be implemented by developers and it is
> just nice to have feature.
>
> Example:
>
> user type ear, but it isn't in wordlist.
>
> Regards the mapping,
> E is similar to A, C, F, O
> A is similar to E, C, O
> R is similar to B, P, H
>
> So application can calculate combinations of possible characters:
>
> a) when app consider than the the user mistyped only one character
> AAR, CAR, FAR, OAR
> EER, ECR, EOR
> EAB, EAP, EAH
>
> b) when app consider than user maybe mistyped more characters, it may do
> full combination matrix
> AEB, ACB, AOB, ... OEH, OCH, OOH
>
> and then ask user to select only these combinations which are actually
> presented in the wordlist. In this particular case it may be only CAR or
> FAR (both cannot be in the wordlist because of rules in similarity).
>
> Marek
>
>
> On Fri, Nov 1, 2013 at 9:14 PM, Brooks Boyd <boydb at midnightdesign.ws>wrote:
>
>> 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=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131101/3609f0da/attachment.html>

2023-06-07 15:08:22

- reply

📅 Original date posted:2013-11-01
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131101/94fd83a9/attachment.html>