Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 07:40:38PM -0500, Rhavar via bitcoin-dev wrote: > I think you're under-appreciating how useful the "plausible deniability". > Someone I know was (solo) traveling to the United States when a border agent > asked her to unlocked her phone; thumbed through her apps, ended up

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

I think you're under-appreciating how useful the "plausible deniability". Someone I know was (solo) traveling to the United States when a border agent asked her to unlocked her phone; thumbed through her apps, ended up finding tinder and went through all her recent conversations to make sure

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Tue, Jan 09, 2018 at 09:26:17AM +1100, Ben Kloester wrote: > > This sounds very dangerous. As Gregory Maxwell pointed out, the key > derivation > > function is weak enough that passphrases could be easily brute forced > > So you are essentially imagining that a perpetrator will combine the >

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak wrote: > On 08/01/18 05:22, Gregory Maxwell wrote: >>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md > > Hey Gregory! > > Thanks for looking into the scheme. I appreciate your time! > >> This specification forces

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

> This sounds very dangerous. As Gregory Maxwell pointed out, the key derivation > function is weak enough that passphrases could be easily brute forced So you are essentially imagining that a perpetrator will combine the crypto-nerd fantasy (brute forcing the passphrase) *with* the 5-dollar

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote: > On 08/01/18 13:45, Peter Todd wrote: > > Can you explain _exactly_ what scenario the "plausible deniability" feature > > refers to? > > >

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

That's the point indeed and the scope is wider than XYZIP-39, even if what I mean is the very contrary of your point (really bitcoin is reserved to an elite understanding english/ascii letters?) This proposal is tailor made for Trezor and does not simplify anything for people, that's the contrary

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

>I'm shocked that so many people are resisting the idea that just *maybe* there could be people in other parts of the world who do not want to use or cannot use the strict set of latin characters and words from the English language. You're mistaking concern for users potentially losing money

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

Greg yes, there were already examples in this very thread of people explaining how they use languages other than English. I'm shocked that so many people are resisting the idea that just *maybe* there could be people in other parts of the world who do not want to use or cannot use the strict set

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

> Let me re-phrase: Is it a known thing for users to actually use it? yes. Based on language stats from the app stores, roughly 30% to 40% of Copay users have their backup on a language other than English, and we constantly get requests to support new languages in BIP39. On Mon, Jan 8, 2018 at

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Has anyone actually used the multilingual support in bip39? > Copay (and all its clones) use it. > > If a feature of the standard has not been(widely?) used in years, and > isn't

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

Let me re-phrase: Is it a known thing for users to actually use it? On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia wrote: > > > On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Has anyone actually used

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

Has anyone actually used the multilingual support in bip39? If a feature of the standard has not been(widely?) used in years, and isn't supported in any major wallet(?), it seems indicative it was a mistake to add it in the first place, since it's a footgun in the making for some poor sap who

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On 2018-01-08 at 04:22:43 + Gregory Maxwell wrote: I'm happy to see that there is no obvious way to abuse this one as a brainwallet scheme! BIP 39 was designed to make brainwallets secure! If a user generates a weakling 12-word mnemonic from 16 tiny octets of entropy

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

On 2018-01-08 at 07:35:52 +, 木ノ下じょな wrote: This is very sad. The number one problem in Japan with BIP39 seeds is with English words. I have seen a 60 year old Japanese man writing down his phrase (because he kept on failing recovery), and watched him write down

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On 08/01/18 13:45, Peter Todd wrote: > Can you explain _exactly_ what scenario the "plausible deniability" feature > refers to? https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO,

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 01:39:20PM +0100, Pavol Rusnak via bitcoin-dev wrote: > > The construction also > > will silently result in the user getting a different private key if > > they enter the wrong passphrase-- which could lead to funds loss. > > Again, this is by design and it is main point

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On 08/01/18 05:22, Gregory Maxwell wrote: >> https://github.com/satoshilabs/slips/blob/master/slip-0039.md Hey Gregory! Thanks for looking into the scheme. I appreciate your time! > This specification forces the key being used through a one way > function, -- so you cannot take a pre-existing