Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ADF6D3EE for ; Sat, 30 Sep 2017 09:35:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5AF8157 for ; Sat, 30 Sep 2017 09:35:06 +0000 (UTC) Received: by mail-qk0-f171.google.com with SMTP id w134so1658384qkb.0 for ; Sat, 30 Sep 2017 02:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jn1oizFJk33DnOkyT32C7NN5/adRgjYmHpSuFfhqCBc=; b=M4K1kcW+yqkEinbisyqCHUQrB5ur0JyWpI/oHU9HAu8zgS7IOWNq8TBxXxCEwNF14e QK8x5NzMzr5aqAJrtHvP/j6siiEE9TY4FriSR6cQHvkruIWbXfyiMhMmKHIF6XW5HuJ5 s4xaGxN9Zev834wBdGOOUK50KE4ho9f9S6xwYtF3/lS5t2ocgRlpAcqy/F4wr9PPcDeQ FZ1MRXD93dlvvTGa/4hsnbi2ICbSQJ5fx9A4QWw6EPQNg++UqZlrCfyzkaEfIlcDMYzW K9dRRD20ZZXu2e823AvKeMkb24Bd8GNl220ydz0HFnsWbJpZ3hbm8RF0kFmXzAz7BgZg d3GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jn1oizFJk33DnOkyT32C7NN5/adRgjYmHpSuFfhqCBc=; b=B8q0xsB9LEsorfrzOl2Pg0Ceb6UAgk1vKXkQwhk5YT7yOkJLwVkyE/lq7CvAfhBn0s M+Atuwuitw1+XVOhDE2AktsQdHNxNr/diQfDZItnNvOE0X6hrmxmwk+vlA5VT301Wtqs hikIXAp3EgMao37Y8GKNP3+lNm/TySIw1O33lLsqQCTPg/JMmWrI7dwEA7Et85VnNTe4 89BDdmMfuWN0FUxBx+OCbkgUtkdyjWNK0hrZG8WIoqguyzZ9K77Ty92ouDoKG7epHoRJ pENZQx1ERq0ZsvcOe5/aXHHrUPE83vL5NTTRVjWWs/yuHkZ7s/RC0tq+j/vljn/hNe7O ptgw== X-Gm-Message-State: AMCzsaUYSZWRY0H06n1H56nei0uuDMv8NGb+nGdS29glV2bKTyM31kS2 Q1KPDWPtgGz4q2i60CwFkTTVe5UJ18aWrQCZYJA= X-Google-Smtp-Source: AOwi7QCtm83CNpZWn7qqr8jUoiFHWYEE/MySz3J2hKeds0yEMP46sy76GgXaxrcsiGNnvrj4cN9kkqXCrgXbEYHOuY8= X-Received: by 10.55.21.30 with SMTP id f30mr7305407qkh.335.1506764105803; Sat, 30 Sep 2017 02:35:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.161.69 with HTTP; Sat, 30 Sep 2017 02:35:05 -0700 (PDT) In-Reply-To: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch> References: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch> From: Adam Ritter Date: Sat, 30 Sep 2017 11:35:05 +0200 Message-ID: To: Dan Libby , Jonas Schnelli , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1147da4e496c65055a64dbf0" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 30 Sep 2017 10:40:49 +0000 Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 09:35:07 -0000 --001a1147da4e496c65055a64dbf0 Content-Type: text/plain; charset="UTF-8" I'm happy to help with secure paper wallet support. Bitcoin core is already used offline by the Glacier Protocol, though there's no official offline support. I extended the Glacier Protocol with an extra password derivation function. I used Scrypt with 2GB RAM requirement, though maybe using Argon2id V1.3 would be better. Also I'd prefer using BIP45 Multisig HD Wallets over a multisig address, as in the current Glacier Protocol implementation the redeem key is public because of the test withdrawal transaction. On Sat, Sep 30, 2017 at 6:49 AM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Hi, > > > > I'm writing to suggest and discuss the addition of paper wallet > > functionality in bitcoin-core software, starting with a single new RPC > > call: genExternalAddress [type]. > > > > AFAIK, client implementations such as your proposal are off-topic for this > ML. > Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for > such proposals. > > > > On 09/29/2017 02:03 PM, Luke Dashjr wrote: > > Paper wallets are a safety hazard, insecure, and generally not advisable. > > > > I have to agree with Luke. > And I would also extend those concerns to BIP39 plaintext paper backups. > > IMO, private keys should be generated and used (signing) on a trusted, > minimal and offline hardware/os. They should never leave the device over > the channel used for the signing I/O. Users should have no way to view or > export the private keys (expect for the seed backup). Backups should be > encrypted (whoever finds the paper backup should need a second factor to > decrypt) and the restore process should be footgun-safe (especially the > lost-passphrase deadlock). > > > /jonas > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1147da4e496c65055a64dbf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy to help with secure paper wallet support. Bi= tcoin core is already used offline by the Glacier Protocol, though there= 9;s no official offline support.

I extended the Glacier Protoc= ol with an extra password derivation function. I used Scrypt with 2GB RAM r= equirement, though maybe using Argon2id V1.3 would be better.

Also I'd prefer using BIP45 Multisig HD Wallets over = a multisig address, as in the current Glacier Protocol implementation the r= edeem key is public because of the test withdrawal transaction.

On Sat, Sep 30, 2017 at= 6:49 AM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@= lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm writing to suggest and discuss the addition of paper wallet > functionality in bitcoin-core software, starting with a single new RPC=
> call: genExternalAddress [type].
>

AFAIK, client implementations such as your proposal are off-topic fo= r this ML.
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for suc= h proposals.


> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> Paper wallets are a safety hazard, insecure, and generally not advisab= le.
>

I have to agree with Luke.
And I would also extend those concerns to BIP39 plaintext paper backups.
IMO, private keys should be generated and used (signing) on a trusted, mini= mal and offline hardware/os. They should never leave the device over the ch= annel used for the signing I/O. Users should have no way to view or export = the private keys (expect for the seed backup). Backups should be encrypted = (whoever finds the paper backup should need a second factor to decrypt) and= the restore process should be footgun-safe (especially the lost-passphrase= deadlock).


/jonas

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a1147da4e496c65055a64dbf0--