Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45822A7A for ; 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 ; 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 ; Tue, 12 Sep 2017 12:07:02 +0000 (UTC) Received: by mail-ua0-f181.google.com with SMTP id s15so14713890uag.1 for ; 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 Date: Tue, 12 Sep 2017 17:36:40 +0530 X-Gmail-Original-Message-ID: Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > To: Mark Friedenbach > Cc: bitcoin-dev > Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call > semantics for generalized MAST > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > > On 12 Sep 2017, at 10:03 AM, Mark Friedenbach > 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 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 > 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 > >> To: bitcoin-dev@lists.linuxfoundation.org > >> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for > >> BIP-32 wallets > >> Message-ID: > >> 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 > >> To: Andreas Schildbach , Bitcoin Protocol > >> Discussion > >> 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 > >> To: Russell O'Connor > >> Cc: Bitcoin Protocol Discussion > >> > >> 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: > >> > >> CHECKSIGVERIFY HASH160 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 EQUALVERIFY CHECKSIGVERIFY HASH160 > >> 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 > > >> wrote: > >>> > >>> > >>> > >>> On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach >> > 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: >> attachments/20170907/63af0292/attachment-0001.html> > >> > >> ------------------------------ > >> > >> Message: 4 > >> Date: Thu, 7 Sep 2017 22:39:17 +0200 > >> From: Thomas Voegtlin > >> To: "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 > To: Anthony Towns , Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Responsible disclosure of bugs > Message-ID: > 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: 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
Thanks Thomas for pointing me to bip173. If everyone is fi= ne, we should go forward with formalizing Thomas' proposal asap. Alread= y 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 maili= ng list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-request@lists.linuxfoundation.org
You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Re: Merkle branch verification & tail-call semantics fo= r
=C2=A0 =C2=A0 =C2=A0 generalized MAST (Johnson Lau)
=C2=A0 =C2=A02. Re: Proposal: Extended serialization format for BIP-32
=C2=A0 =C2=A0 =C2=A0 (Thomas Voegtlin)
=C2=A0 =C2=A03. 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@fried= enbach.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics for generalized MAST
Message-ID: <DA22C531-2FAE-4332-B158-A3F96BF34002@xbt.hk>
Content-Type: text/plain; charset=3Dutf-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<= br> > 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. Th= is 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<= br> > on the main stack.

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

>
>> I think you have also missed the sigOp counting of the executed >> script. As you can't count it without executing the script, th= e
>> current static analysability is lost. This was one of the reasons<= br> >> for OP_EVAL being rejected. Since sigOp is a per-block limit, any<= br> >> 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<= br> > 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<= br> > 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 i= t (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.h= tml). 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) 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: http://hackingdistributed.com/2016/06/28/ethereum-soft-= fork-dos-vector/

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.

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.

>
> 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<= br> >> 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, li= ke
>> <30 lines of code? It looks complex now because it does much mo= re
>> 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/f3f201d232d3995db38e09b171e4d1dea8d04a= d2

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> https://gi= thub.com/jl2012/bips/blob/vault/bip-0114.mediawiki#Additional_scr= ipts_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 fr= om 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@e= lectrum.org>
To: bitcoin-dev@li= sts.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BIP-32
Message-ID: <99643f72-f72f-e4e9-ac2b-72bf519c25b5@electrum.org> Content-Type: text/plain; charset=3Dutf-8



On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> I understand the motivation of adding the birthdate field. However, no= t
> very comfortable with having this in the public key serialization. The= re
> are privacy implication of both the birthday field and having the comp= lete
> derivation path, which takes space.
> > I am fine with Thomas proposal of {x,y,z}. Having additional vers= ion byte
> field looks modular but since since we already have the big enough ver= sion
> field in bip32, better to use that instead of adding more bytes.
>
> Thomas, can you please explain why we require different version for P2= WPKH
> 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, <
> bitco= in-dev-request@lists.linuxfoundation.org> wrote:
>
>> Send bitcoin-dev mailing list submissions to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev@lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v
>> or, via email, send a message with subject or body 'help' = to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev-request@lists.linuxfoundat= ion.org
>>
>> You can reach the person managing the list at
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev-owner@lists.linuxfoundation.= org
>>
>> When replying, please edit your Subject line so it is more specifi= c
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>>=C2=A0 =C2=A0 1. Re: Proposal: Extended serialization format for=C2= =A0 =C2=A0BIP-32
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Andreas Schildbach)
>>=C2=A0 =C2=A0 2. Re: Proposal: Extended serialization format for BI= P-32
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Pavol Rusnak)
>>=C2=A0 =C2=A0 3. Re: Fast Merkle Trees (Mark Friedenbach)
>>=C2=A0 =C2=A0 4. Re: Proposal: Extended serialization format for BI= P-32
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Thomas Voegtlin)
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>>
>> Message: 1
>> Date: Thu, 7 Sep 2017 21:35:49 +0200
>> From: Andreas Schildbach <andreas@schildbach.de>
>> To: bitco= in-dev@lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets
>> Message-ID: <oos72e$rjp$1= @blaine.gmane.org>
>> Content-Type: text/plain; charset=3Dutf-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 u= se BIP43
>>>
>>> What if we added another byte field OutputType for wallets tha= t 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 d= epth=3D=3D0x00
>>> 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 ar= e
>> mixed. In this case the field should be omitted and the wallet nee= ds 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 <st= ick@satoshilabs.com>
>> To: Andreas Schildbach <andreas@schildbach.de>, Bitcoin Protocol
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discussion <bitcoin-dev@lists.linuxfoundati= on.org>
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets
>> Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c733ba@satoshilabs= .com>
>> Content-Type: text/plain; charset=3Dwindows-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 mak= e
>> 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 type= s 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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<bitcoin-dev@lists.linuxfoundation.org&= gt;
>> Subject: Re: [bitcoin-dev] Fast Merkle Trees
>> Message-ID: <40D6F502-3380-4B64-BCD9-80D361EED35C@friedenbach= .org>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> TL;DR I'll be updating the fast Merkle-tree spec to use a diff= erent
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0IV, using (for infrastructure compatabil= ity reasons) the scheme
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by Peter Todd.
>>
>> This is a specific instance of a general problem where you cannot<= br> >> trust scripts given to you by another party. Notice that we run in= to
>> the same sort of problem when doing key aggregation, in which you = must
>> require the other party to prove knowledge of the discrete log bef= ore
>> using their public key, or else key cancellation can occur.
>>
>> With script it is a little bit more complicated as you might want<= br> >> zero-knowledge proofs of hash pre-images for HTLCs as well as proo= fs
>> of DL knowledge (signatures), but the basic idea is the same. Mult= i-
>> party wallet level protocols for jointly constructing scriptPubKey= s
>> should require a 'delinearization' step that proves knowle= dge 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 specif= y a
>> key they control and take the funds that way.
>>
>> Where this presumably leads to an actual exploit is when you speci= fy a
>> script that a curious counter-party actually takes the time to
>> investigate and believes to be secure. For example, a script that<= br> >> requires a signature or pre-image revelation from that counter-par= ty.
>> That would require grinding not a few bytes, but at minimum 20-33<= br> >> bytes for either a HASH160 image or the counter-party's key. >>
>> If I understand the revised attack description correctly, then the= re
>> is a small window in which the attacker can create a script less t= han
>> 55 bytes in length, where nearly all of the first 32 bytes are
>> selected by the attacker, yet nevertheless the script seems safe t= o
>> the counter-party. The smallest such script I was able to construc= t
>> was the following:
>>
>>=C2=A0 =C2=A0 =C2=A0<fake-pubkey> CHECKSIGVERIFY HASH160 <= preimage> EQUAL
>>
>> This is 56 bytes and requires only 7 bits of grinding in the fake<= br> >> pubkey. But 56 bytes is too large. Switching to secp256k1 serializ= ed
>> 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:
>>
>>=C2=A0 =C2=A0 =C2=A0DUP HASH160 <fake-pubkey-hash> EQUALVERIF= Y CHECKSIGVERIFY HASH160
>> <preimage> EQUAL
>>
>> This is 46 bytes, but requires grinding 96 bits, which is a bit le= ss
>> plausible.
>>
>> Belts and suspenders are not so terrible together, however, and I<= br> >> think there is enough of a justification here to look into modifyi= ng
>> 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@friedenbac= h.org>> wrote:
>>> I've been puzzling over your email since receiving it. I&#= 39;m not sure it
>>> is possible to perform the attack you describe with the tree s= tructure
>>> 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
>>>
>>>=C2=A0 =C2=A0 double-SHA256(innocuous)
>>>
>>> is equal to either
>>>
>>>=C2=A0 =C2=A0 fast-SHA256(double-SHA256(malign) || r) or >>>=C2=A0 =C2=A0 fast-SHA256(r || double-SHA256(malign))
>>>
>>> or=C2=A0 fast-SHA256(fast-SHA256(double-SHA256(malign) ||= r1) || r0)
>>> or=C2=A0 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 thi= s can be
>>> accomplished without a full break of SHA256.
>>>
>>> The particular scenario I'm imagining is a collision betwe= en
>>>
>>>=C2=A0 =C2=A0 =C2=A0double-SHA256(innocuous)
>>>
>>> and
>>>
>>>=C2=A0 =C2=A0 =C2=A0fast-SHA256(fast-SHA256(fast-SHA256(do= uble-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-SHA25= 6(data) =3D
>> 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 collisio= n between
>>>
>>>=C2=A0 =C2=A0 =C2=A0padding-SHA256(innocuous)
>>>
>>> and
>>>
>>>=C2=A0 =C2=A0 =C2=A0fast-SHA256(double-SHA256(malign) || r= 2) || r1
>>>
>>> r1 can freely be set to the second half of padding-SHA256(inno= cuous), so
>> it suffices to find a collision between
>>>
>>>=C2=A0 =C2=A0 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 t= hat the
>> attacker claims to be his 33-byte public key.
>>> So long as the attacker doesn't need to prove that they kn= ow 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.=C2=A0 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.linuxfoundatio= n.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"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<bitcoin-dev@lists.linuxfoundation.org&= gt;
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets
>> Message-ID: <9e74dc17-105c-b43c-7780-4fa690043fe2@electrum.org>
>> Content-Type: text/plain; charset=3Dwindows-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 u= se BIP43
>>>
>>> What if we added another byte field OutputType for wallets tha= t 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 d= epth=3D=3D0x00
>>> or at all times. What is your suggestion, Thomas?
>>>
>>
>>
>> well, in my initial proposal, I wrote that this value should be us= er
>> 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, w= hich
>> leaves the xpub/xprv prefix unchanged). I have experimented with t= hat
>> 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 cr= eate a
>> 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By<= br> >> 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 add= resses.
>>
>> 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 pr= obably
>> do not need a serialization format.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@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@l= ists.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.a= u>,=C2=A0 Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAKzdR-oYQ8EchpJVE56yJbfBgN= Hihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.com>
Content-Type: text/plain; charset=3D"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<= br> 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).<= br>
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 t= he majority
> would
> > greatly appreciate the disclosure and would behave responsibly wi= th 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 f= ive 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<= br> > advantage for attackers against people who haven't upgraded for ot= her
> reasons?
>
> I find it hard to imagine bitcoin's still obscure enough that peop= le
> aren't tracking git commit logs to use them as inspiration for att= acks
> 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<= br> > 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,<= br> > being able to be exploited by otherwise legitimate bitcoin businesses<= br> > with an agenda to push, a strong financial motive behind that agenda,<= br> > and a legal team that says they'll get away with it)
>
> > 2- Unlike other software, I'm not sure good security for bitc= oin is
> defined by
> > constant upgrading.=C2=A0 Obviously upgrading has an important be= nefit, but
> one of
> > the security considerations for Bitcoin is knowing that your defi= nition
> of the
> > money hasn't changed.=C2=A0 Much harder to know that if you c= hange software.
>
> Isn't that just an argument for putting more effort into backporti= ng
> fixes/workarounds? (I don't see how you do that without essentiall= y
> 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<= br> > positive network effect, where having other people upgrade can help yo= ur
> 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<= br> > 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 thei= r
> upstream to make their own job easier; either helping with backports,<= br> > or perhaps contributing to patches like PR#8994 might help.
>
> All of those things seem like they'd help not just altcoins but bi= tcoin
> investors/traders too, so it's not even a trade-off between classe= s of
> bitcoin core users.=C2=A0 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?
>=C2=A0 =C2=A0 =C2=A0I've no idea which of those might have trustwor= thy devs to work with,
>=C2=A0 =C2=A0 =C2=A0but surely at least a couple do?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.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/a= ttachments/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--