path: root/5e/69436b6cb3952249609c24b22c8521bad55b71

Return-Path: <shiva@blockonomics.co>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 45822A7A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 12:07:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from blockonomics.co (blockonomics.co [52.10.115.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 945DCA4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 12:07:03 +0000 (UTC)
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com
	[209.85.217.181])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by blockonomics.co (Postfix) with ESMTPSA id CE9321E4295
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 12:07:02 +0000 (UTC)
Received: by mail-ua0-f181.google.com with SMTP id s15so14713890uag.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 05:07:02 -0700 (PDT)
X-Gm-Message-State: AHPjjUj0tLhqQw/HWtonrfqlwLHBh/MS4L7Rk/eOUhp8zot95hb6vSsS
	ZiGSqemDuECMUAYbr4yNLRw1wSQp3w==
X-Google-Smtp-Source: AOwi7QDeIeJotplUFJJ+UGvfzup+vz659W4gjy0i56LUWbevpA5Qtdqrw0emwRPuoHdOQQdrb2A+flPH3EscaEXF1Xo=
X-Received: by 10.159.49.206 with SMTP id w14mr11942057uad.197.1505218021475; 
	Tue, 12 Sep 2017 05:07:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.75.9 with HTTP; Tue, 12 Sep 2017 05:06:40 -0700 (PDT)
From: shiva sitamraju <shiva@blockonomics.co>
Date: Tue, 12 Sep 2017 17:36:40 +0530
X-Gmail-Original-Message-ID: <CABuOfugNbyF-O0p42ghHm546XvV3FcMscb-pb4MeQA_akNHipw@mail.gmail.com>
Message-ID: <CABuOfugNbyF-O0p42ghHm546XvV3FcMscb-pb4MeQA_akNHipw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a1144ed1c7ade4f0558fce188"
X-Spam-Status: No, score=0.5 required=5.0 tests=HTML_MESSAGE,
	RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD 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: Tue, 12 Sep 2017 12:20:01 +0000
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 12:07:07 -0000

--001a1144ed1c7ade4f0558fce188
Content-Type: text/plain; charset="UTF-8"

Thanks Thomas for pointing me to bip173. If everyone is fine, we should go
forward with formalizing Thomas' proposal asap. Already segwit wallet
usage/demand is increasing !

On Tue, Sep 12, 2017 at 4:54 PM, <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Merkle branch verification & tail-call semantics for
>       generalized MAST (Johnson Lau)
>    2. Re: Proposal: Extended serialization format for BIP-32
>       (Thomas Voegtlin)
>    3. Re: Responsible disclosure of bugs (Sergio Demian Lerner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 Sep 2017 16:55:59 +0800
> From: Johnson Lau <jl2012@xbt.hk>
> To: Mark Friedenbach <mark@friedenbach.org>
> Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call
>         semantics for generalized MAST
> Message-ID: <DA22C531-2FAE-4332-B158-A3F96BF34002@xbt.hk>
> Content-Type: text/plain; charset=utf-8
>
>
> > On 12 Sep 2017, at 10:03 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
> >
> > My apologies for a delay in responding to emails on this list; I have
> > been fighting a cold.
> >
> > (Also my apologies to Johnson Lau, as I forgot to forward this to the
> list.)
> >
> > On Sep 8, 2017, at 2:21 AM, Johnson Lau <jl2012@xbt.hk> wrote:
> >
> >> Tail-call execution semantics require "unclean stake" , i.e. final
> >> stake with more than one item. However, "unclean stake" is invalid
> >> (not just non-standard) in BIP141, so you could only use it with
> >> legacy P2SH (which is totally pointless....). A different design
> >> like OP_EVAL might be needed, or you need a new witness script
> >> version.
> >
> > I believe you meant "unclean stack," and you are correct. This was
> > also pointed out last tuesday by a participant at the in-person
> > CoreDev meetup where the idea was presented.
> >
> > This doesn't kill the idea, it just complicates the implementation
> > slightly. A simple fix would be to allow tail-recursion to occur if
> > the stack is not clean (as can happen with legacy P2SH as you point
> > out, or yet to be defined version 1+ forms of segwit script), OR if
> > there is a single item on the stack and the alt-stack is not empty.
> > For segwit v0 scripts you then have to move any arguments to the alt
> > stack before ending the redeem script, leaving just the policy script
> > on the main stack.
>
> This is ugly and actually broken, as different script path may require
> different number of stack items, so you don?t know how many OP_TOALTSTACK
> do you need. Easier to just use a new witness version
>
> >
> >> I think you have also missed the sigOp counting of the executed
> >> script. As you can't count it without executing the script, the
> >> current static analysability is lost. This was one of the reasons
> >> for OP_EVAL being rejected. Since sigOp is a per-block limit, any
> >> OP_EVAL-like operation means block validity will depend on the
> >> precise outcome of script execution (instead of just pass or fail),
> >> which is a layer violation.
> >
> > I disagree with this design requirement.
> >
> > The SigOp counting method used by bitcoin is flawed. It incorrectly
> > limits not the number of signature operations necessary to validate a
> > block, but rather the number of CHECKSIGs potentially encountered in
> > script execution, even if in an unexecuted branch. (Admitedly MAST
> > makes this less of an issue, but there are still useful compact
> > scripts that use if/else constructs to elide a CHECKSIG.) Nor will it
> > account for aggregation when that feature is added, or properly
> > differentiate between signature operations that can be batched and
> > those that can not.
> >
> > Additionally there are other resources used by script that should be
> > globally limited, such as hash operations, which are not accounted for
> > at this time and cannot be statically assessed, even by the flawed
> > mechanism by which SigOps are counted. I have maintained for some time
> > that bitcoin should move from having multiple separate global limits
> > (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear
> > metric that combines all of these factors with appropriate
> > coefficients.
> >
>
> I like the idea to have an unified global limit and suggested a way to do
> it (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/
> 013472.html). But I think this is off-topic here.
>
>
>
> > A better way of handling this problem, which works for both SigOps and
> > HashOps, is to have the witness commit to the maximum resources
> > consumed by validation of the spend of the coin, to relay this data
> > with the transaction and include it in the SigHash, and to use the
> > committed maximum for block validation. This could be added in a
> > future script version upgrade. This change would also resolve the
> > issue that led to the clean stack rule in segwit, allowing future
> > versions of script to use tail-call recursion without involving the
> > alt-stack.
> >
> > Nevertheless it is constructive feedback that the current draft of the
> > BIP and its implementation do not count SigOps, at all. There are a
> > couple of ways this can be fixed by evaluating the top-level script
> > and then doing static analysis of the resulting policy script, or by
> > running the script and counting operations actually performed.
>
>
> In any case, I think maintaining static analysability for global limit(s)
> is very important. Ethereum had to give up their DAO softfork plan at the
> last minute, exactly due to the lack of this:
> http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
>
> Otherwise, one could attack relay and mining nodes by sending many small
> size txs with many sigops, forcing them to validate, and discard due to
> insufficient fees.
>
> Technically it might be ok if we commit the total validation cost (sigop +
> hashop + whatever) as the first witness stack item, but that?d take more
> space and I?m not sure if it is desirable. Anyway, giving up static
> analysability for scripts is a fundamental change to our existing model.
>
> >
> > Additionally, it is possible that we take this time to re-evaluate
> > whether we should be counting SigOps other than for legacy consensus
> > rule compliance. The speed of verification in secp256k1 has made
> > signature operations no longer the chief concern in block validation
> > times.
>
> Without the limit I think we would be DoS-ed to dead
>
>
> >> Witness script versioning is by design fully compatible with P2SH
> >> and BIP173, so there will be no hurdle for existing wallets to pay
> >> to BIP114. Actually it should be completely transparent to them.
> >
> > This is correct. Your feedback will be incorporated.
> >
> >> For code complexity, the minimal BIP114 could be really simple, like
> >> <30 lines of code? It looks complex now because it does much more
> >> than simply hiding scripts in a hash.
> >
> > Is there a repo that contains the latest implementation of BIP 114,
> > for comparison purposes?
>
>
> You can find it here: https://github.com/jl2012/bitcoin/commits/vault
> https://github.com/jl2012/bitcoin/commit/f3f201d232d3995db38e09b171e4d1
> dea8d04ad2
>
> But this does more than your proposal as it allows users adding extra
> scripts when spending a coin. The rationale is described in the revised
> BIP114:
> https://github.com/jl2012/bips/blob/vault/bip-0114.
> mediawiki#Additional_scripts_in_witness
>
> So to make it functionally comparable with your proposal, the
> IsMSV0Stack() function is not needed. The new 249-254 lines in
> interpreter.cpp could be removed. The new 1480-1519 lines could be replaced
> by a few lines copied from the existing P2WSH code. I can make a minimal
> version if you want to see how it looks like
>
>
> >
> > Kind regards,
> > Mark Friedenbach
> >
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 12 Sep 2017 11:06:15 +0200
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>         BIP-32
> Message-ID: <99643f72-f72f-e4e9-ac2b-72bf519c25b5@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:
> > Hi,
> >
> > I understand the motivation of adding the birthdate field. However, not
> > very comfortable with having this in the public key serialization. There
> > are privacy implication of both the birthday field and having the
> complete
> > derivation path, which takes space.
> > > I am fine with Thomas proposal of {x,y,z}. Having additional version
> byte
> > field looks modular but since since we already have the big enough
> version
> > field in bip32, better to use that instead of adding more bytes.
> >
> > Thomas, can you please explain why we require different version for
> P2WPKH
> > or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that
> they
> > would have the same output bitcoin address and under same account.
>
> no, native scripts do not have the same address. see bip173
>
>
> >
> > On Fri, Sep 8, 2017 at 2:09 AM, <
> > bitcoin-dev-request@lists.linuxfoundation.org> wrote:
> >
> >> Send bitcoin-dev mailing list submissions to
> >>         bitcoin-dev@lists.linuxfoundation.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> or, via email, send a message with subject or body 'help' to
> >>         bitcoin-dev-request@lists.linuxfoundation.org
> >>
> >> You can reach the person managing the list at
> >>         bitcoin-dev-owner@lists.linuxfoundation.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of bitcoin-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. Re: Proposal: Extended serialization format for   BIP-32
> >>       wallets (Andreas Schildbach)
> >>    2. Re: Proposal: Extended serialization format for BIP-32
> >>       wallets (Pavol Rusnak)
> >>    3. Re: Fast Merkle Trees (Mark Friedenbach)
> >>    4. Re: Proposal: Extended serialization format for BIP-32
> >>       wallets (Thomas Voegtlin)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Thu, 7 Sep 2017 21:35:49 +0200
> >> From: Andreas Schildbach <andreas@schildbach.de>
> >> To: bitcoin-dev@lists.linuxfoundation.org
> >> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
> >>         BIP-32 wallets
> >> Message-ID: <oos72e$rjp$1@blaine.gmane.org>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
> >>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
> >>>> A solution is still needed to wallets who do not wish to use BIP43
> >>>
> >>> What if we added another byte field OutputType for wallets that do not
> >>> follow BIP43?
> >>>
> >>> 0x00 - P2PKH output type
> >>> 0x01 - P2WPKH-in-P2SH output type
> >>> 0x02 - native Segwit output type
> >>>
> >>> Would that work for you?
> >>
> >> I think that would work.
> >>
> >>> The question is whether this field should be present only if
> depth==0x00
> >>> or at all times. What is your suggestion, Thomas?
> >>
> >> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
> >> we need this field. I think it should always be present if a chain is
> >> limited to a certain script type.
> >>
> >> There is however the case where even on one chain, script types are
> >> mixed. In this case the field should be omitted and the wallet needs to
> >> scan for all (known) types. Afaik Bitcoin Core is taking this path.
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Thu, 7 Sep 2017 22:00:05 +0200
> >> From: Pavol Rusnak <stick@satoshilabs.com>
> >> To: Andreas Schildbach <andreas@schildbach.de>, Bitcoin Protocol
> >>         Discussion <bitcoin-dev@lists.linuxfoundation.org>
> >> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
> >>         BIP-32 wallets
> >> Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c733ba@satoshilabs.com>
> >> Content-Type: text/plain; charset=windows-1252
> >>
> >> On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
> >>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
> >>> we need this field.
> >>
> >> But the depth of exported public key will be null. It does not make
> >> sense to export xpub for m or m/0' for your particular case.
> >>
> >>> I think it should always be present if a chain is
> >>> limited to a certain script type.
> >>
> >> I am fine with having the path there all the time.
> >>
> >>> There is however the case where even on one chain, script types are
> >>> mixed. In this case the field should be omitted and the wallet needs to
> >>> scan for all (known) types. Afaik Bitcoin Core is taking this path.
> >>
> >> Is that really the case? Why come up with a hierarchy and then don't use
> >> it?
> >>
> >> --
> >> Best Regards / S pozdravom,
> >>
> >> Pavol "stick" Rusnak
> >> CTO, SatoshiLabs
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Thu, 7 Sep 2017 13:04:30 -0700
> >> From: Mark Friedenbach <mark@friedenbach.org>
> >> To: Russell O'Connor <roconnor@blockstream.io>
> >> Cc: Bitcoin Protocol Discussion
> >>         <bitcoin-dev@lists.linuxfoundation.org>
> >> Subject: Re: [bitcoin-dev] Fast Merkle Trees
> >> Message-ID: <40D6F502-3380-4B64-BCD9-80D361EED35C@friedenbach.org>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> TL;DR I'll be updating the fast Merkle-tree spec to use a different
> >>       IV, using (for infrastructure compatability reasons) the scheme
> >>       provided by Peter Todd.
> >>
> >> This is a specific instance of a general problem where you cannot
> >> trust scripts given to you by another party. Notice that we run into
> >> the same sort of problem when doing key aggregation, in which you must
> >> require the other party to prove knowledge of the discrete log before
> >> using their public key, or else key cancellation can occur.
> >>
> >> With script it is a little bit more complicated as you might want
> >> zero-knowledge proofs of hash pre-images for HTLCs as well as proofs
> >> of DL knowledge (signatures), but the basic idea is the same. Multi-
> >> party wallet level protocols for jointly constructing scriptPubKeys
> >> should require a 'delinearization' step that proves knowledge of
> >> information necessary to complete each part of the script, as part of
> >> proving the safety of a construct.
> >>
> >> I think my hangup before in understanding the attack you describe was
> >> in actualizing it into a practical attack that actually escalates the
> >> attacker's capabilities. If the attacker can get you to agree to a
> >> MAST policy that is nothing more than a CHECKSIG over a key they
> >> presumably control, then they don't need to do any complicated
> >> grinding. The attacker in that scenario would just actually specify a
> >> key they control and take the funds that way.
> >>
> >> Where this presumably leads to an actual exploit is when you specify a
> >> script that a curious counter-party actually takes the time to
> >> investigate and believes to be secure. For example, a script that
> >> requires a signature or pre-image revelation from that counter-party.
> >> That would require grinding not a few bytes, but at minimum 20-33
> >> bytes for either a HASH160 image or the counter-party's key.
> >>
> >> If I understand the revised attack description correctly, then there
> >> is a small window in which the attacker can create a script less than
> >> 55 bytes in length, where nearly all of the first 32 bytes are
> >> selected by the attacker, yet nevertheless the script seems safe to
> >> the counter-party. The smallest such script I was able to construct
> >> was the following:
> >>
> >>     <fake-pubkey> CHECKSIGVERIFY HASH160 <preimage> EQUAL
> >>
> >> This is 56 bytes and requires only 7 bits of grinding in the fake
> >> pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
> >> 32-byte pubkeys (in a script version upgrade, for example) would
> >> reduce this to the necessary 55 bytes with 0 bits of grinding. A
> >> smaller variant is possible:
> >>
> >>     DUP HASH160 <fake-pubkey-hash> EQUALVERIFY CHECKSIGVERIFY HASH160
> >> <preimage> EQUAL
> >>
> >> This is 46 bytes, but requires grinding 96 bits, which is a bit less
> >> plausible.
> >>
> >> Belts and suspenders are not so terrible together, however, and I
> >> think there is enough of a justification here to look into modifying
> >> the scheme to use a different IV for hash tree updates. This would
> >> prevent even the above implausible attacks.
> >>
> >>
> >>> On Sep 7, 2017, at 11:55 AM, Russell O'Connor <roconnor@blockstream.io
> >
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach <mark@friedenbach.org
> >> <mailto:mark@friedenbach.org>> wrote:
> >>> I've been puzzling over your email since receiving it. I'm not sure it
> >>> is possible to perform the attack you describe with the tree structure
> >>> specified in the BIP. If I may rephrase your attack, I believe you are
> >>> seeking a solution to the following:
> >>>
> >>> Want: An innocuous script and a malign script for which
> >>>
> >>>    double-SHA256(innocuous)
> >>>
> >>> is equal to either
> >>>
> >>>    fast-SHA256(double-SHA256(malign) || r) or
> >>>    fast-SHA256(r || double-SHA256(malign))
> >>>
> >>> or  fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
> >>> or  fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
> >>> or ...
> >>>
> >>> where r is a freely chosen 32-byte nonce. This would allow the
> >>> attacker to reveal the innocuous script before funds are sent to the
> >>> MAST, then use the malign script to spend.
> >>>
> >>> Because of the double-SHA256 construction I do not see how this can be
> >>> accomplished without a full break of SHA256.
> >>>
> >>> The particular scenario I'm imagining is a collision between
> >>>
> >>>     double-SHA256(innocuous)
> >>>
> >>> and
> >>>
> >>>     fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2)
> ||
> >> r1) || r0).
> >>>
> >>> where innocuous is a Bitcoin Script that is between 32 and 55 bytes
> long.
> >>>
> >>> Observe that when data is less than 55 bytes then double-SHA256(data) =
> >> fast-SHA256(fast-SHA256(padding-SHA256(data)) || 0x8000...100) (which
> is
> >> really the crux of the matter).
> >>>
> >>> Therefore, to get our collision it suffices to find a collision between
> >>>
> >>>     padding-SHA256(innocuous)
> >>>
> >>> and
> >>>
> >>>     fast-SHA256(double-SHA256(malign) || r2) || r1
> >>>
> >>> r1 can freely be set to the second half of padding-SHA256(innocuous),
> so
> >> it suffices to find a collision between
> >>>
> >>>    fast-SHA256(double-SHA256(malign) || r2)
> >>>
> >>> and the first half of padding-SHA256(innocuous) which is equal to the
> >> first 32 bytes of innocuous.
> >>>
> >>> Imagine the first opcode of innocuous is the push of a value that the
> >> attacker claims to be his 33-byte public key.
> >>> So long as the attacker doesn't need to prove that they know the
> >> discrete log of this pubkey, they can grind r2 until the result of
> >> fast-SHA256(double-SHA256(malign) || r2) contains the correct first
> >> couple of bytes for the script header and the opcode for a 33-byte
> push.  I
> >> believe that is only about 3 or 4 bytes of they need to grind out.
> >>>
> >>
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> >> attachments/20170907/63af0292/attachment-0001.html>
> >>
> >> ------------------------------
> >>
> >> Message: 4
> >> Date: Thu, 7 Sep 2017 22:39:17 +0200
> >> From: Thomas Voegtlin <thomasv@electrum.org>
> >> To: "bitcoin-dev@lists.linuxfoundation.org"
> >>         <bitcoin-dev@lists.linuxfoundation.org>
> >> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
> >>         BIP-32 wallets
> >> Message-ID: <9e74dc17-105c-b43c-7780-4fa690043fe2@electrum.org>
> >> Content-Type: text/plain; charset=windows-1252
> >>
> >>
> >>
> >> On 07.09.2017 18:23, Pavol Rusnak wrote:
> >>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
> >>>> A solution is still needed to wallets who do not wish to use BIP43
> >>>
> >>> What if we added another byte field OutputType for wallets that do not
> >>> follow BIP43?
> >>>
> >>> 0x00 - P2PKH output type
> >>> 0x01 - P2WPKH-in-P2SH output type
> >>> 0x02 - native Segwit output type
> >>>
> >>> Would that work for you?
> >>>
> >>> The question is whether this field should be present only if
> depth==0x00
> >>> or at all times. What is your suggestion, Thomas?
> >>>
> >>
> >>
> >> well, in my initial proposal, I wrote that this value should be user
> >> visible. That is why I used version bytes. If you create an extra byte
> >> field, and then use base58 or bech32 encoding, the value will not be
> >> user visible anymore.
> >>
> >> The initial implementation of segwit xpub/xprv in Electrum used a flag
> >> that was not user visible (I added 1 to the bip32 version bytes, which
> >> leaves the xpub/xprv prefix unchanged). I have experimented with that
> >> invisible flag for more than 6 months now, and I am now convinced that
> >> it is better to make that flag user visible.
> >>
> >> The reason is that when users create wallets with multisig scripts, they
> >> need to combine several master public keys. However, these master public
> >> keys should all be of the same type: it would not make sense to create a
> >> 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By
> >> imposing that all master keys are of the same type, we ensure that all
> >> cosigners agree on the script type that will be used to derive
> addresses.
> >>
> >> In other words, if users are exposed to master keys and need to
> >> manipulate them, it is better to let them see what they are doing.
> >>
> >> OTOH if you do not plan to expose your users to these keys, you probably
> >> do not need a serialization format.
> >>
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> End of bitcoin-dev Digest, Vol 28, Issue 17
> >> *******************************************
> >>
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> --
> Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany
> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> Gesch?ftsf?hrer: Thomas Voegtlin
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 12 Sep 2017 01:49:34 -0300
> From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
> To: Anthony Towns <aj@erisian.com.au>,  Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
> Message-ID:
>         <CAKzdR-oYQ8EchpJVE56yJbfBgNHihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.
> com>
> Content-Type: text/plain; charset="utf-8"
>
> Historically people have published vulnerabilities in Bitcoin only after
> >80% of the nodes have upgraded. This seems to be the general (but not
> publicly stated) policy. If you're a core developer and you know better,
> please correct me.
>
> This means that:
>
> - a critical vulnerability, like a remote code execution, will be patched
> immediately (without disclosing the actual problem) and all participants
> will be notified asap. This is no different from any other open source
> project. An example of this case was the OpenSSL Heartbleed vulnerability
> that affected Bitcoin.
>
> - a non-critical vulnerability, either because miners only can exploit it
> or because it requires vast resources to pull, may require a wait of years
> before publication, after a vulnerability was found and reported. This is
> because the "natural" node upgrade rate is slow.
>
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher cannot report to alt-coins which have a different
> policy.
>
> This policy has nothing to do with a loyalty to Bitcoin Core (or in fact,
> the two or so developers that actually receive the e-mails to
> security@bitcoincore.org).
>
> This is a policy that has simply proven to work to protect Bitcoiners. It
> began long long ago.
>
>
>
> On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> > > I don't think I know the right answer here, but I will point out two
> > things
> > > that make this a little more complicated.
> > > 1 - There are lots of altcoin developers and while I'm sure the
> majority
> > would
> > > greatly appreciate the disclosure and would behave responsibly with the
> > > information, I don't know where you draw the line on who you tell and
> > who you
> > > don't.
> >
> > If you can't pick even a small group that's trustworthy (top five by
> > market cap as a start [0]? or just major bitcoin wallets / exchanges /
> > alt node implementations?), then it still seems better to (eventually)
> > disclose publically than keep it unrevealed and let it be a potential
> > advantage for attackers against people who haven't upgraded for other
> > reasons?
> >
> > I find it hard to imagine bitcoin's still obscure enough that people
> > aren't tracking git commit logs to use them as inspiration for attacks
> > on bitcoin users and businesses; at best I would have thought it'd
> > only be a few months of development time between a fix being proposed
> > as a PR or committed to master and black hats having the ability to
> > exploit it in users who are running older nodes. (Or for that matter,
> > being able to be exploited by otherwise legitimate bitcoin businesses
> > with an agenda to push, a strong financial motive behind that agenda,
> > and a legal team that says they'll get away with it)
> >
> > > 2- Unlike other software, I'm not sure good security for bitcoin is
> > defined by
> > > constant upgrading.  Obviously upgrading has an important benefit, but
> > one of
> > > the security considerations for Bitcoin is knowing that your definition
> > of the
> > > money hasn't changed.  Much harder to know that if you change software.
> >
> > Isn't that just an argument for putting more effort into backporting
> > fixes/workarounds? (I don't see how you do that without essentially
> > publically disclosing which patches have a security impact -- "oh,
> > gosh, this patch gets a backport, I wonder if maybe it has security
> > implications...")
> >
> > (In so far as bitcoin is a consensus system, there can sometimes be a
> > positive network effect, where having other people upgrade can help your
> > security, even if you don't upgrade; "herd immunity" if you will. That
> > way a new release going out to other people helps keep you safe, even
> > while you continue to maintain the same definition of money by not
> > upgrading at all)
> >
> > If altcoin maintainers are inconvenienced by tracking bitcoin-core
> > updates, that would be an argument for them to contribute back to their
> > upstream to make their own job easier; either helping with backports,
> > or perhaps contributing to patches like PR#8994 might help.
> >
> > All of those things seem like they'd help not just altcoins but bitcoin
> > investors/traders too, so it's not even a trade-off between classes of
> > bitcoin core users.  And if in the end various altcoins aren't able to
> > keep up with security fixes, that's probably valuable information to
> > provide to the market...
> >
> > Cheers,
> > aj
> >
> > [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
> >     I've no idea which of those might have trustworthy devs to work with,
> >     but surely at least a couple do?
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170912/78a88c9e/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 28, Issue 26
> *******************************************
>

--001a1144ed1c7ade4f0558fce188
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks Thomas for pointing me to bip173. If everyone is fi=
ne, we should go forward with formalizing Thomas&#39; proposal asap. Alread=
y segwit wallet usage/demand is increasing ! <br><div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Tue, Sep 12, 2017 at 4:54 PM,  <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send bitcoin-dev maili=
ng list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br=
>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org">bitcoin-dev-owner@lists.<wbr>linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. Re: Merkle branch verification &amp; tail-call semantics fo=
r<br>
=C2=A0 =C2=A0 =C2=A0 generalized MAST (Johnson Lau)<br>
=C2=A0 =C2=A02. Re: Proposal: Extended serialization format for BIP-32<br>
=C2=A0 =C2=A0 =C2=A0 (Thomas Voegtlin)<br>
=C2=A0 =C2=A03. Re: Responsible disclosure of bugs (Sergio Demian Lerner)<b=
r>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----=
-----<br>
<br>
Message: 1<br>
Date: Tue, 12 Sep 2017 16:55:59 +0800<br>
From: Johnson Lau &lt;<a href=3D"mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt=
;<br>
To: Mark Friedenbach &lt;<a href=3D"mailto:mark@friedenbach.org">mark@fried=
enbach.org</a>&gt;<br>
Cc: bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Merkle branch verification &amp; tail-call<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics for generalized MAST<br>
Message-ID: &lt;<a href=3D"mailto:DA22C531-2FAE-4332-B158-A3F96BF34002@xbt.=
hk">DA22C531-2FAE-4332-B158-<wbr>A3F96BF34002@xbt.hk</a>&gt;<br>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
<br>
&gt; On 12 Sep 2017, at 10:03 AM, Mark Friedenbach &lt;<a href=3D"mailto:ma=
rk@friedenbach.org">mark@friedenbach.org</a>&gt; wrote:<br>
&gt;<br>
&gt; My apologies for a delay in responding to emails on this list; I have<=
br>
&gt; been fighting a cold.<br>
&gt;<br>
&gt; (Also my apologies to Johnson Lau, as I forgot to forward this to the =
list.)<br>
&gt;<br>
&gt; On Sep 8, 2017, at 2:21 AM, Johnson Lau &lt;<a href=3D"mailto:jl2012@x=
bt.hk">jl2012@xbt.hk</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Tail-call execution semantics require &quot;unclean stake&quot; , =
i.e. final<br>
&gt;&gt; stake with more than one item. However, &quot;unclean stake&quot; =
is invalid<br>
&gt;&gt; (not just non-standard) in BIP141, so you could only use it with<b=
r>
&gt;&gt; legacy P2SH (which is totally pointless....). A different design<b=
r>
&gt;&gt; like OP_EVAL might be needed, or you need a new witness script<br>
&gt;&gt; version.<br>
&gt;<br>
&gt; I believe you meant &quot;unclean stack,&quot; and you are correct. Th=
is was<br>
&gt; also pointed out last tuesday by a participant at the in-person<br>
&gt; CoreDev meetup where the idea was presented.<br>
&gt;<br>
&gt; This doesn&#39;t kill the idea, it just complicates the implementation=
<br>
&gt; slightly. A simple fix would be to allow tail-recursion to occur if<br=
>
&gt; the stack is not clean (as can happen with legacy P2SH as you point<br=
>
&gt; out, or yet to be defined version 1+ forms of segwit script), OR if<br=
>
&gt; there is a single item on the stack and the alt-stack is not empty.<br=
>
&gt; For segwit v0 scripts you then have to move any arguments to the alt<b=
r>
&gt; stack before ending the redeem script, leaving just the policy script<=
br>
&gt; on the main stack.<br>
<br>
This is ugly and actually broken, as different script path may require diff=
erent number of stack items, so you don?t know how many OP_TOALTSTACK do yo=
u need. Easier to just use a new witness version<br>
<br>
&gt;<br>
&gt;&gt; I think you have also missed the sigOp counting of the executed<br=
>
&gt;&gt; script. As you can&#39;t count it without executing the script, th=
e<br>
&gt;&gt; current static analysability is lost. This was one of the reasons<=
br>
&gt;&gt; for OP_EVAL being rejected. Since sigOp is a per-block limit, any<=
br>
&gt;&gt; OP_EVAL-like operation means block validity will depend on the<br>
&gt;&gt; precise outcome of script execution (instead of just pass or fail)=
,<br>
&gt;&gt; which is a layer violation.<br>
&gt;<br>
&gt; I disagree with this design requirement.<br>
&gt;<br>
&gt; The SigOp counting method used by bitcoin is flawed. It incorrectly<br=
>
&gt; limits not the number of signature operations necessary to validate a<=
br>
&gt; block, but rather the number of CHECKSIGs potentially encountered in<b=
r>
&gt; script execution, even if in an unexecuted branch. (Admitedly MAST<br>
&gt; makes this less of an issue, but there are still useful compact<br>
&gt; scripts that use if/else constructs to elide a CHECKSIG.) Nor will it<=
br>
&gt; account for aggregation when that feature is added, or properly<br>
&gt; differentiate between signature operations that can be batched and<br>
&gt; those that can not.<br>
&gt;<br>
&gt; Additionally there are other resources used by script that should be<b=
r>
&gt; globally limited, such as hash operations, which are not accounted for=
<br>
&gt; at this time and cannot be statically assessed, even by the flawed<br>
&gt; mechanism by which SigOps are counted. I have maintained for some time=
<br>
&gt; that bitcoin should move from having multiple separate global limits<b=
r>
&gt; (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear=
<br>
&gt; metric that combines all of these factors with appropriate<br>
&gt; coefficients.<br>
&gt;<br>
<br>
I like the idea to have an unified global limit and suggested a way to do i=
t (<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-=
January/013472.html" rel=3D"noreferrer" target=3D"_blank">https://lists.<wb=
r>linuxfoundation.org/pipermail/<wbr>bitcoin-dev/2017-January/<wbr>013472.h=
tml</a>). But I think this is off-topic here.<br>
<br>
<br>
<br>
&gt; A better way of handling this problem, which works for both SigOps and=
<br>
&gt; HashOps, is to have the witness commit to the maximum resources<br>
&gt; consumed by validation of the spend of the coin, to relay this data<br=
>
&gt; with the transaction and include it in the SigHash, and to use the<br>
&gt; committed maximum for block validation. This could be added in a<br>
&gt; future script version upgrade. This change would also resolve the<br>
&gt; issue that led to the clean stack rule in segwit, allowing future<br>
&gt; versions of script to use tail-call recursion without involving the<br=
>
&gt; alt-stack.<br>
&gt;<br>
&gt; Nevertheless it is constructive feedback that the current draft of the=
<br>
&gt; BIP and its implementation do not count SigOps, at all. There are a<br=
>
&gt; couple of ways this can be fixed by evaluating the top-level script<br=
>
&gt; and then doing static analysis of the resulting policy script, or by<b=
r>
&gt; running the script and counting operations actually performed.<br>
<br>
<br>
In any case, I think maintaining static analysability for global limit(s) i=
s very important. Ethereum had to give up their DAO softfork plan at the la=
st minute, exactly due to the lack of this: <a href=3D"http://hackingdistri=
buted.com/2016/06/28/ethereum-soft-fork-dos-vector/" rel=3D"noreferrer" tar=
get=3D"_blank">http://hackingdistributed.com/<wbr>2016/06/28/ethereum-soft-=
fork-<wbr>dos-vector/</a><br>
<br>
Otherwise, one could attack relay and mining nodes by sending many small si=
ze txs with many sigops, forcing them to validate, and discard due to insuf=
ficient fees.<br>
<br>
Technically it might be ok if we commit the total validation cost (sigop + =
hashop + whatever) as the first witness stack item, but that?d take more sp=
ace and I?m not sure if it is desirable. Anyway, giving up static analysabi=
lity for scripts is a fundamental change to our existing model.<br>
<br>
&gt;<br>
&gt; Additionally, it is possible that we take this time to re-evaluate<br>
&gt; whether we should be counting SigOps other than for legacy consensus<b=
r>
&gt; rule compliance. The speed of verification in secp256k1 has made<br>
&gt; signature operations no longer the chief concern in block validation<b=
r>
&gt; times.<br>
<br>
Without the limit I think we would be DoS-ed to dead<br>
<br>
<br>
&gt;&gt; Witness script versioning is by design fully compatible with P2SH<=
br>
&gt;&gt; and BIP173, so there will be no hurdle for existing wallets to pay=
<br>
&gt;&gt; to BIP114. Actually it should be completely transparent to them.<b=
r>
&gt;<br>
&gt; This is correct. Your feedback will be incorporated.<br>
&gt;<br>
&gt;&gt; For code complexity, the minimal BIP114 could be really simple, li=
ke<br>
&gt;&gt; &lt;30 lines of code? It looks complex now because it does much mo=
re<br>
&gt;&gt; than simply hiding scripts in a hash.<br>
&gt;<br>
&gt; Is there a repo that contains the latest implementation of BIP 114,<br=
>
&gt; for comparison purposes?<br>
<br>
<br>
You can find it here: <a href=3D"https://github.com/jl2012/bitcoin/commits/=
vault" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl2012/<wbr>=
bitcoin/commits/vault</a><br>
<a href=3D"https://github.com/jl2012/bitcoin/commit/f3f201d232d3995db38e09b=
171e4d1dea8d04ad2" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
jl2012/<wbr>bitcoin/commit/<wbr>f3f201d232d3995db38e09b171e4d1<wbr>dea8d04a=
d2</a><br>
<br>
But this does more than your proposal as it allows users adding extra scrip=
ts when spending a coin. The rationale is described in the revised BIP114:<=
br>
<a href=3D"https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki#Add=
itional_scripts_in_witness" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/jl2012/<wbr>bips/blob/vault/bip-0114.<wbr>mediawiki#Additional_scr=
ipts_<wbr>in_witness</a><br>
<br>
So to make it functionally comparable with your proposal, the IsMSV0Stack()=
 function is not needed. The new 249-254 lines in interpreter.cpp could be =
removed. The new 1480-1519 lines could be replaced by a few lines copied fr=
om the existing P2WSH code. I can make a minimal version if you want to see=
 how it looks like<br>
<br>
<br>
&gt;<br>
&gt; Kind regards,<br>
&gt; Mark Friedenbach<br>
&gt;<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 12 Sep 2017 11:06:15 +0200<br>
From: Thomas Voegtlin &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@e=
lectrum.org</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BIP-32<br>
Message-ID: &lt;<a href=3D"mailto:99643f72-f72f-e4e9-ac2b-72bf519c25b5@elec=
trum.org">99643f72-f72f-e4e9-ac2b-<wbr>72bf519c25b5@electrum.org</a>&gt;<br=
>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
<br>
<br>
On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I understand the motivation of adding the birthdate field. However, no=
t<br>
&gt; very comfortable with having this in the public key serialization. The=
re<br>
&gt; are privacy implication of both the birthday field and having the comp=
lete<br>
&gt; derivation path, which takes space.<br>
&gt; &gt; I am fine with Thomas proposal of {x,y,z}. Having additional vers=
ion byte<br>
&gt; field looks modular but since since we already have the big enough ver=
sion<br>
&gt; field in bip32, better to use that instead of adding more bytes.<br>
&gt;<br>
&gt; Thomas, can you please explain why we require different version for P2=
WPKH<br>
&gt; or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that=
 they<br>
&gt; would have the same output bitcoin address and under same account.<br>
<br>
no, native scripts do not have the same address. see bip173<br>
<br>
<br>
&gt;<br>
&gt; On Fri, Sep 8, 2017 at 2:09 AM, &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitco=
in-dev-request@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Send bitcoin-dev mailing list submissions to<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;<br>
&gt;&gt; To subscribe or unsubscribe via the World Wide Web, visit<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_bla=
nk">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>de=
v</a><br>
&gt;&gt; or, via email, send a message with subject or body &#39;help&#39; =
to<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev-req=
uest@lists.linuxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundat=
ion.org</a><br>
&gt;&gt;<br>
&gt;&gt; You can reach the person managing the list at<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev-own=
er@lists.linuxfoundation.org">bitcoin-dev-owner@lists.<wbr>linuxfoundation.=
org</a><br>
&gt;&gt;<br>
&gt;&gt; When replying, please edit your Subject line so it is more specifi=
c<br>
&gt;&gt; than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Today&#39;s Topics:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 1. Re: Proposal: Extended serialization format for=C2=
=A0 =C2=A0BIP-32<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Andreas Schildbach)<br>
&gt;&gt;=C2=A0 =C2=A0 2. Re: Proposal: Extended serialization format for BI=
P-32<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Pavol Rusnak)<br>
&gt;&gt;=C2=A0 =C2=A0 3. Re: Fast Merkle Trees (Mark Friedenbach)<br>
&gt;&gt;=C2=A0 =C2=A0 4. Re: Proposal: Extended serialization format for BI=
P-32<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Thomas Voegtlin)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------<wbr>------------------------------<=
wbr>----------<br>
&gt;&gt;<br>
&gt;&gt; Message: 1<br>
&gt;&gt; Date: Thu, 7 Sep 2017 21:35:49 +0200<br>
&gt;&gt; From: Andreas Schildbach &lt;<a href=3D"mailto:andreas@schildbach.=
de">andreas@schildbach.de</a>&gt;<br>
&gt;&gt; To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; Subject: Re: [bitcoin-dev] Proposal: Extended serialization format=
 for<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br>
&gt;&gt; Message-ID: &lt;oos72e$rjp$<a href=3D"mailto:1@blaine.gmane.org">1=
@blaine.gmane.org</a><wbr>&gt;<br>
&gt;&gt; Content-Type: text/plain; charset=3Dutf-8<br>
&gt;&gt;<br>
&gt;&gt; On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:<br>
&gt;&gt;&gt; On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:<br>
&gt;&gt;&gt;&gt; A solution is still needed to wallets who do not wish to u=
se BIP43<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What if we added another byte field OutputType for wallets tha=
t do not<br>
&gt;&gt;&gt; follow BIP43?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 0x00 - P2PKH output type<br>
&gt;&gt;&gt; 0x01 - P2WPKH-in-P2SH output type<br>
&gt;&gt;&gt; 0x02 - native Segwit output type<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Would that work for you?<br>
&gt;&gt;<br>
&gt;&gt; I think that would work.<br>
&gt;&gt;<br>
&gt;&gt;&gt; The question is whether this field should be present only if d=
epth=3D=3D0x00<br>
&gt;&gt;&gt; or at all times. What is your suggestion, Thomas?<br>
&gt;&gt;<br>
&gt;&gt; In case of Bitcoin Wallet, the depth is not null (m/0&#39;/[0,1]) =
and still<br>
&gt;&gt; we need this field. I think it should always be present if a chain=
 is<br>
&gt;&gt; limited to a certain script type.<br>
&gt;&gt;<br>
&gt;&gt; There is however the case where even on one chain, script types ar=
e<br>
&gt;&gt; mixed. In this case the field should be omitted and the wallet nee=
ds to<br>
&gt;&gt; scan for all (known) types. Afaik Bitcoin Core is taking this path=
.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------<br>
&gt;&gt;<br>
&gt;&gt; Message: 2<br>
&gt;&gt; Date: Thu, 7 Sep 2017 22:00:05 +0200<br>
&gt;&gt; From: Pavol Rusnak &lt;<a href=3D"mailto:stick@satoshilabs.com">st=
ick@satoshilabs.com</a>&gt;<br>
&gt;&gt; To: Andreas Schildbach &lt;<a href=3D"mailto:andreas@schildbach.de=
">andreas@schildbach.de</a>&gt;, Bitcoin Protocol<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discussion &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundati=
on.org</a>&gt;<br>
&gt;&gt; Subject: Re: [bitcoin-dev] Proposal: Extended serialization format=
 for<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br>
&gt;&gt; Message-ID: &lt;<a href=3D"mailto:40ed03a1-915c-33b0-c4ac-e898c8c7=
33ba@satoshilabs.com">40ed03a1-915c-33b0-c4ac-<wbr>e898c8c733ba@satoshilabs=
.com</a>&gt;<br>
&gt;&gt; Content-Type: text/plain; charset=3Dwindows-1252<br>
&gt;&gt;<br>
&gt;&gt; On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:<br>
&gt;&gt;&gt; In case of Bitcoin Wallet, the depth is not null (m/0&#39;/[0,=
1]) and still<br>
&gt;&gt;&gt; we need this field.<br>
&gt;&gt;<br>
&gt;&gt; But the depth of exported public key will be null. It does not mak=
e<br>
&gt;&gt; sense to export xpub for m or m/0&#39; for your particular case.<b=
r>
&gt;&gt;<br>
&gt;&gt;&gt; I think it should always be present if a chain is<br>
&gt;&gt;&gt; limited to a certain script type.<br>
&gt;&gt;<br>
&gt;&gt; I am fine with having the path there all the time.<br>
&gt;&gt;<br>
&gt;&gt;&gt; There is however the case where even on one chain, script type=
s are<br>
&gt;&gt;&gt; mixed. In this case the field should be omitted and the wallet=
 needs to<br>
&gt;&gt;&gt; scan for all (known) types. Afaik Bitcoin Core is taking this =
path.<br>
&gt;&gt;<br>
&gt;&gt; Is that really the case? Why come up with a hierarchy and then don=
&#39;t use<br>
&gt;&gt; it?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Best Regards / S pozdravom,<br>
&gt;&gt;<br>
&gt;&gt; Pavol &quot;stick&quot; Rusnak<br>
&gt;&gt; CTO, SatoshiLabs<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------<br>
&gt;&gt;<br>
&gt;&gt; Message: 3<br>
&gt;&gt; Date: Thu, 7 Sep 2017 13:04:30 -0700<br>
&gt;&gt; From: Mark Friedenbach &lt;<a href=3D"mailto:mark@friedenbach.org"=
>mark@friedenbach.org</a>&gt;<br>
&gt;&gt; To: Russell O&#39;Connor &lt;<a href=3D"mailto:roconnor@blockstrea=
m.io">roconnor@blockstream.io</a>&gt;<br>
&gt;&gt; Cc: Bitcoin Protocol Discussion<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&=
gt;<br>
&gt;&gt; Subject: Re: [bitcoin-dev] Fast Merkle Trees<br>
&gt;&gt; Message-ID: &lt;<a href=3D"mailto:40D6F502-3380-4B64-BCD9-80D361EE=
D35C@friedenbach.org">40D6F502-3380-4B64-BCD9-<wbr>80D361EED35C@friedenbach=
.org</a>&gt;<br>
&gt;&gt; Content-Type: text/plain; charset=3D&quot;us-ascii&quot;<br>
&gt;&gt;<br>
&gt;&gt; TL;DR I&#39;ll be updating the fast Merkle-tree spec to use a diff=
erent<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0IV, using (for infrastructure compatabil=
ity reasons) the scheme<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by Peter Todd.<br>
&gt;&gt;<br>
&gt;&gt; This is a specific instance of a general problem where you cannot<=
br>
&gt;&gt; trust scripts given to you by another party. Notice that we run in=
to<br>
&gt;&gt; the same sort of problem when doing key aggregation, in which you =
must<br>
&gt;&gt; require the other party to prove knowledge of the discrete log bef=
ore<br>
&gt;&gt; using their public key, or else key cancellation can occur.<br>
&gt;&gt;<br>
&gt;&gt; With script it is a little bit more complicated as you might want<=
br>
&gt;&gt; zero-knowledge proofs of hash pre-images for HTLCs as well as proo=
fs<br>
&gt;&gt; of DL knowledge (signatures), but the basic idea is the same. Mult=
i-<br>
&gt;&gt; party wallet level protocols for jointly constructing scriptPubKey=
s<br>
&gt;&gt; should require a &#39;delinearization&#39; step that proves knowle=
dge of<br>
&gt;&gt; information necessary to complete each part of the script, as part=
 of<br>
&gt;&gt; proving the safety of a construct.<br>
&gt;&gt;<br>
&gt;&gt; I think my hangup before in understanding the attack you describe =
was<br>
&gt;&gt; in actualizing it into a practical attack that actually escalates =
the<br>
&gt;&gt; attacker&#39;s capabilities. If the attacker can get you to agree =
to a<br>
&gt;&gt; MAST policy that is nothing more than a CHECKSIG over a key they<b=
r>
&gt;&gt; presumably control, then they don&#39;t need to do any complicated=
<br>
&gt;&gt; grinding. The attacker in that scenario would just actually specif=
y a<br>
&gt;&gt; key they control and take the funds that way.<br>
&gt;&gt;<br>
&gt;&gt; Where this presumably leads to an actual exploit is when you speci=
fy a<br>
&gt;&gt; script that a curious counter-party actually takes the time to<br>
&gt;&gt; investigate and believes to be secure. For example, a script that<=
br>
&gt;&gt; requires a signature or pre-image revelation from that counter-par=
ty.<br>
&gt;&gt; That would require grinding not a few bytes, but at minimum 20-33<=
br>
&gt;&gt; bytes for either a HASH160 image or the counter-party&#39;s key.<b=
r>
&gt;&gt;<br>
&gt;&gt; If I understand the revised attack description correctly, then the=
re<br>
&gt;&gt; is a small window in which the attacker can create a script less t=
han<br>
&gt;&gt; 55 bytes in length, where nearly all of the first 32 bytes are<br>
&gt;&gt; selected by the attacker, yet nevertheless the script seems safe t=
o<br>
&gt;&gt; the counter-party. The smallest such script I was able to construc=
t<br>
&gt;&gt; was the following:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0&lt;fake-pubkey&gt; CHECKSIGVERIFY HASH160 &lt;=
preimage&gt; EQUAL<br>
&gt;&gt;<br>
&gt;&gt; This is 56 bytes and requires only 7 bits of grinding in the fake<=
br>
&gt;&gt; pubkey. But 56 bytes is too large. Switching to secp256k1 serializ=
ed<br>
&gt;&gt; 32-byte pubkeys (in a script version upgrade, for example) would<b=
r>
&gt;&gt; reduce this to the necessary 55 bytes with 0 bits of grinding. A<b=
r>
&gt;&gt; smaller variant is possible:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0DUP HASH160 &lt;fake-pubkey-hash&gt; EQUALVERIF=
Y CHECKSIGVERIFY HASH160<br>
&gt;&gt; &lt;preimage&gt; EQUAL<br>
&gt;&gt;<br>
&gt;&gt; This is 46 bytes, but requires grinding 96 bits, which is a bit le=
ss<br>
&gt;&gt; plausible.<br>
&gt;&gt;<br>
&gt;&gt; Belts and suspenders are not so terrible together, however, and I<=
br>
&gt;&gt; think there is enough of a justification here to look into modifyi=
ng<br>
&gt;&gt; the scheme to use a different IV for hash tree updates. This would=
<br>
&gt;&gt; prevent even the above implausible attacks.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Sep 7, 2017, at 11:55 AM, Russell O&#39;Connor &lt;<a href=
=3D"mailto:roconnor@blockstream.io">roconnor@blockstream.io</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach &lt;<a href=
=3D"mailto:mark@friedenbach.org">mark@friedenbach.org</a><br>
&gt;&gt; &lt;mailto:<a href=3D"mailto:mark@friedenbach.org">mark@friedenbac=
h.org</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt; I&#39;ve been puzzling over your email since receiving it. I&#=
39;m not sure it<br>
&gt;&gt;&gt; is possible to perform the attack you describe with the tree s=
tructure<br>
&gt;&gt;&gt; specified in the BIP. If I may rephrase your attack, I believe=
 you are<br>
&gt;&gt;&gt; seeking a solution to the following:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Want: An innocuous script and a malign script for which<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 double-SHA256(innocuous)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; is equal to either<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 fast-SHA256(double-SHA256(<wbr>malign) || r) or<b=
r>
&gt;&gt;&gt;=C2=A0 =C2=A0 fast-SHA256(r || double-SHA256(malign))<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; or=C2=A0 fast-SHA256(fast-SHA256(<wbr>double-SHA256(malign) ||=
 r1) || r0)<br>
&gt;&gt;&gt; or=C2=A0 fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) =
|| r0)<br>
&gt;&gt;&gt; or ...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; where r is a freely chosen 32-byte nonce. This would allow the=
<br>
&gt;&gt;&gt; attacker to reveal the innocuous script before funds are sent =
to the<br>
&gt;&gt;&gt; MAST, then use the malign script to spend.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Because of the double-SHA256 construction I do not see how thi=
s can be<br>
&gt;&gt;&gt; accomplished without a full break of SHA256.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The particular scenario I&#39;m imagining is a collision betwe=
en<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0double-SHA256(innocuous)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; and<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0fast-SHA256(fast-SHA256(fast-<wbr>SHA256(do=
uble-SHA256(malign) || r2) ||<br>
&gt;&gt; r1) || r0).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; where innocuous is a Bitcoin Script that is between 32 and 55 =
bytes long.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Observe that when data is less than 55 bytes then double-SHA25=
6(data) =3D<br>
&gt;&gt; fast-SHA256(fast-SHA256(<wbr>padding-SHA256(data)) || 0x8000...100=
) (which is<br>
&gt;&gt; really the crux of the matter).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Therefore, to get our collision it suffices to find a collisio=
n between<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0padding-SHA256(innocuous)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; and<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0fast-SHA256(double-SHA256(<wbr>malign) || r=
2) || r1<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; r1 can freely be set to the second half of padding-SHA256(inno=
cuous), so<br>
&gt;&gt; it suffices to find a collision between<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0 fast-SHA256(double-SHA256(<wbr>malign) || r2)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; and the first half of padding-SHA256(innocuous) which is equal=
 to the<br>
&gt;&gt; first 32 bytes of innocuous.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Imagine the first opcode of innocuous is the push of a value t=
hat the<br>
&gt;&gt; attacker claims to be his 33-byte public key.<br>
&gt;&gt;&gt; So long as the attacker doesn&#39;t need to prove that they kn=
ow the<br>
&gt;&gt; discrete log of this pubkey, they can grind r2 until the result of=
<br>
&gt;&gt; fast-SHA256(double-SHA256(<wbr>malign) || r2) contains the correct=
 first<br>
&gt;&gt; couple of bytes for the script header and the opcode for a 33-byte=
 push.=C2=A0 I<br>
&gt;&gt; believe that is only about 3 or 4 bytes of they need to grind out.=
<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; -------------- next part --------------<br>
&gt;&gt; An HTML attachment was scrubbed...<br>
&gt;&gt; URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bit=
coin-dev/" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundatio=
n.<wbr>org/pipermail/bitcoin-dev/</a><br>
&gt;&gt; attachments/20170907/63af0292/<wbr>attachment-0001.html&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------<br>
&gt;&gt;<br>
&gt;&gt; Message: 4<br>
&gt;&gt; Date: Thu, 7 Sep 2017 22:39:17 +0200<br>
&gt;&gt; From: Thomas Voegtlin &lt;<a href=3D"mailto:thomasv@electrum.org">=
thomasv@electrum.org</a>&gt;<br>
&gt;&gt; To: &quot;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&quot;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&=
gt;<br>
&gt;&gt; Subject: Re: [bitcoin-dev] Proposal: Extended serialization format=
 for<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br>
&gt;&gt; Message-ID: &lt;<a href=3D"mailto:9e74dc17-105c-b43c-7780-4fa69004=
3fe2@electrum.org">9e74dc17-105c-b43c-7780-<wbr>4fa690043fe2@electrum.org</=
a>&gt;<br>
&gt;&gt; Content-Type: text/plain; charset=3Dwindows-1252<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 07.09.2017 18:23, Pavol Rusnak wrote:<br>
&gt;&gt;&gt; On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:<br>
&gt;&gt;&gt;&gt; A solution is still needed to wallets who do not wish to u=
se BIP43<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What if we added another byte field OutputType for wallets tha=
t do not<br>
&gt;&gt;&gt; follow BIP43?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 0x00 - P2PKH output type<br>
&gt;&gt;&gt; 0x01 - P2WPKH-in-P2SH output type<br>
&gt;&gt;&gt; 0x02 - native Segwit output type<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Would that work for you?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The question is whether this field should be present only if d=
epth=3D=3D0x00<br>
&gt;&gt;&gt; or at all times. What is your suggestion, Thomas?<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; well, in my initial proposal, I wrote that this value should be us=
er<br>
&gt;&gt; visible. That is why I used version bytes. If you create an extra =
byte<br>
&gt;&gt; field, and then use base58 or bech32 encoding, the value will not =
be<br>
&gt;&gt; user visible anymore.<br>
&gt;&gt;<br>
&gt;&gt; The initial implementation of segwit xpub/xprv in Electrum used a =
flag<br>
&gt;&gt; that was not user visible (I added 1 to the bip32 version bytes, w=
hich<br>
&gt;&gt; leaves the xpub/xprv prefix unchanged). I have experimented with t=
hat<br>
&gt;&gt; invisible flag for more than 6 months now, and I am now convinced =
that<br>
&gt;&gt; it is better to make that flag user visible.<br>
&gt;&gt;<br>
&gt;&gt; The reason is that when users create wallets with multisig scripts=
, they<br>
&gt;&gt; need to combine several master public keys. However, these master =
public<br>
&gt;&gt; keys should all be of the same type: it would not make sense to cr=
eate a<br>
&gt;&gt; 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By<=
br>
&gt;&gt; imposing that all master keys are of the same type, we ensure that=
 all<br>
&gt;&gt; cosigners agree on the script type that will be used to derive add=
resses.<br>
&gt;&gt;<br>
&gt;&gt; In other words, if users are exposed to master keys and need to<br=
>
&gt;&gt; manipulate them, it is better to let them see what they are doing.=
<br>
&gt;&gt;<br>
&gt;&gt; OTOH if you do not plan to expose your users to these keys, you pr=
obably<br>
&gt;&gt; do not need a serialization format.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; End of bitcoin-dev Digest, Vol 28, Issue 17<br>
&gt;&gt; ******************************<wbr>*************<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
<br>
--<br>
Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany<br>
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636<br>
Gesch?ftsf?hrer: Thomas Voegtlin<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 12 Sep 2017 01:49:34 -0300<br>
From: Sergio Demian Lerner &lt;<a href=3D"mailto:sergio.d.lerner@gmail.com"=
>sergio.d.lerner@gmail.com</a>&gt;<br>
To: Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.a=
u</a>&gt;,=C2=A0 Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CAKzdR-oYQ8EchpJVE56yJbfB=
gNHihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.com">CAKzdR-<wbr>oYQ8EchpJVE56yJbfBgN=
Hihx7WO_<wbr>gtFtp6QKOcK7uT-w@mail.gmail.<wbr>com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Historically people have published vulnerabilities in Bitcoin only after<br=
>
&gt;80% of the nodes have upgraded. This seems to be the general (but not<b=
r>
publicly stated) policy. If you&#39;re a core developer and you know better=
,<br>
please correct me.<br>
<br>
This means that:<br>
<br>
- a critical vulnerability, like a remote code execution, will be patched<b=
r>
immediately (without disclosing the actual problem) and all participants<br=
>
will be notified asap. This is no different from any other open source<br>
project. An example of this case was the OpenSSL Heartbleed vulnerability<b=
r>
that affected Bitcoin.<br>
<br>
- a non-critical vulnerability, either because miners only can exploit it<b=
r>
or because it requires vast resources to pull, may require a wait of years<=
br>
before publication, after a vulnerability was found and reported. This is<b=
r>
because the &quot;natural&quot; node upgrade rate is slow.<br>
<br>
It also implies that some times a researcher works hard to investigate a<br=
>
vulnerability and later he finds out it was previously reported. It also<br=
>
means that the researcher cannot report to alt-coins which have a different=
<br>
policy.<br>
<br>
This policy has nothing to do with a loyalty to Bitcoin Core (or in fact,<b=
r>
the two or so developers that actually receive the e-mails to<br>
<a href=3D"mailto:security@bitcoincore.org">security@bitcoincore.org</a>).<=
br>
<br>
This is a policy that has simply proven to work to protect Bitcoiners. It<b=
r>
began long long ago.<br>
<br>
<br>
<br>
On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev &lt;<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:<br>
&gt; &gt; I don&#39;t think I know the right answer here, but I will point =
out two<br>
&gt; things<br>
&gt; &gt; that make this a little more complicated.<br>
&gt; &gt; 1 - There are lots of altcoin developers and while I&#39;m sure t=
he majority<br>
&gt; would<br>
&gt; &gt; greatly appreciate the disclosure and would behave responsibly wi=
th the<br>
&gt; &gt; information, I don&#39;t know where you draw the line on who you =
tell and<br>
&gt; who you<br>
&gt; &gt; don&#39;t.<br>
&gt;<br>
&gt; If you can&#39;t pick even a small group that&#39;s trustworthy (top f=
ive by<br>
&gt; market cap as a start [0]? or just major bitcoin wallets / exchanges /=
<br>
&gt; alt node implementations?), then it still seems better to (eventually)=
<br>
&gt; disclose publically than keep it unrevealed and let it be a potential<=
br>
&gt; advantage for attackers against people who haven&#39;t upgraded for ot=
her<br>
&gt; reasons?<br>
&gt;<br>
&gt; I find it hard to imagine bitcoin&#39;s still obscure enough that peop=
le<br>
&gt; aren&#39;t tracking git commit logs to use them as inspiration for att=
acks<br>
&gt; on bitcoin users and businesses; at best I would have thought it&#39;d=
<br>
&gt; only be a few months of development time between a fix being proposed<=
br>
&gt; as a PR or committed to master and black hats having the ability to<br=
>
&gt; exploit it in users who are running older nodes. (Or for that matter,<=
br>
&gt; being able to be exploited by otherwise legitimate bitcoin businesses<=
br>
&gt; with an agenda to push, a strong financial motive behind that agenda,<=
br>
&gt; and a legal team that says they&#39;ll get away with it)<br>
&gt;<br>
&gt; &gt; 2- Unlike other software, I&#39;m not sure good security for bitc=
oin is<br>
&gt; defined by<br>
&gt; &gt; constant upgrading.=C2=A0 Obviously upgrading has an important be=
nefit, but<br>
&gt; one of<br>
&gt; &gt; the security considerations for Bitcoin is knowing that your defi=
nition<br>
&gt; of the<br>
&gt; &gt; money hasn&#39;t changed.=C2=A0 Much harder to know that if you c=
hange software.<br>
&gt;<br>
&gt; Isn&#39;t that just an argument for putting more effort into backporti=
ng<br>
&gt; fixes/workarounds? (I don&#39;t see how you do that without essentiall=
y<br>
&gt; publically disclosing which patches have a security impact -- &quot;oh=
,<br>
&gt; gosh, this patch gets a backport, I wonder if maybe it has security<br=
>
&gt; implications...&quot;)<br>
&gt;<br>
&gt; (In so far as bitcoin is a consensus system, there can sometimes be a<=
br>
&gt; positive network effect, where having other people upgrade can help yo=
ur<br>
&gt; security, even if you don&#39;t upgrade; &quot;herd immunity&quot; if =
you will. That<br>
&gt; way a new release going out to other people helps keep you safe, even<=
br>
&gt; while you continue to maintain the same definition of money by not<br>
&gt; upgrading at all)<br>
&gt;<br>
&gt; If altcoin maintainers are inconvenienced by tracking bitcoin-core<br>
&gt; updates, that would be an argument for them to contribute back to thei=
r<br>
&gt; upstream to make their own job easier; either helping with backports,<=
br>
&gt; or perhaps contributing to patches like PR#8994 might help.<br>
&gt;<br>
&gt; All of those things seem like they&#39;d help not just altcoins but bi=
tcoin<br>
&gt; investors/traders too, so it&#39;s not even a trade-off between classe=
s of<br>
&gt; bitcoin core users.=C2=A0 And if in the end various altcoins aren&#39;=
t able to<br>
&gt; keep up with security fixes, that&#39;s probably valuable information =
to<br>
&gt; provide to the market...<br>
&gt;<br>
&gt; Cheers,<br>
&gt; aj<br>
&gt;<br>
&gt; [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?<br>
&gt;=C2=A0 =C2=A0 =C2=A0I&#39;ve no idea which of those might have trustwor=
thy devs to work with,<br>
&gt;=C2=A0 =C2=A0 =C2=A0but surely at least a couple do?<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20170912/78a88c9e/attachment.html" rel=3D"noreferrer" target=3D=
"_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>a=
ttachments/20170912/78a88c9e/<wbr>attachment.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 28, Issue 26<br>
******************************<wbr>*************<br>
</blockquote></div><br></div></div></div>

--001a1144ed1c7ade4f0558fce188--