diff options
| author | shiva sitamraju <shiva@blockonomics.co> | 2017-09-12 17:36:40 +0530 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-12 12:07:07 +0000 |
| commit | a277f3d18ed8da83f98aaa77c3dc33080d8842de (patch) | |
| tree | fe93db14c49411edd0dc2f3f06ffff9d2c36b94d /5e/69436b6cb3952249609c24b22c8521bad55b71 | |
| parent | c242642f8e89079d9fa07eb640401e1b68330f28 (diff) | |
| download | pi-bitcoindev-a277f3d18ed8da83f98aaa77c3dc33080d8842de.tar.gz pi-bitcoindev-a277f3d18ed8da83f98aaa77c3dc33080d8842de.zip | |
Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32
Diffstat (limited to '5e/69436b6cb3952249609c24b22c8521bad55b71')
| -rw-r--r-- | 5e/69436b6cb3952249609c24b22c8521bad55b71 | 1770 |
1 files changed, 1770 insertions, 0 deletions
diff --git a/5e/69436b6cb3952249609c24b22c8521bad55b71 b/5e/69436b6cb3952249609c24b22c8521bad55b71 new file mode 100644 index 000000000..85d6ea8a8 --- /dev/null +++ b/5e/69436b6cb3952249609c24b22c8521bad55b71 @@ -0,0 +1,1770 @@ +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' 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"><<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundati= +on.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>= +></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 'help' 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 "Re: Contents of bitcoin-dev digest..."<br> +<br> +<br> +Today's Topics:<br> +<br> +=C2=A0 =C2=A01. Re: Merkle branch verification & 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 <<a href=3D"mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>>= +;<br> +To: Mark Friedenbach <<a href=3D"mailto:mark@friedenbach.org">mark@fried= +enbach.org</a>><br> +Cc: bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org= +">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>><br> +Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics for generalized MAST<br> +Message-ID: <<a href=3D"mailto:DA22C531-2FAE-4332-B158-A3F96BF34002@xbt.= +hk">DA22C531-2FAE-4332-B158-<wbr>A3F96BF34002@xbt.hk</a>><br> +Content-Type: text/plain; charset=3Dutf-8<br> +<br> +<br> +> On 12 Sep 2017, at 10:03 AM, Mark Friedenbach <<a href=3D"mailto:ma= +rk@friedenbach.org">mark@friedenbach.org</a>> wrote:<br> +><br> +> My apologies for a delay in responding to emails on this list; I have<= +br> +> been fighting a cold.<br> +><br> +> (Also my apologies to Johnson Lau, as I forgot to forward this to the = +list.)<br> +><br> +> On Sep 8, 2017, at 2:21 AM, Johnson Lau <<a href=3D"mailto:jl2012@x= +bt.hk">jl2012@xbt.hk</a>> wrote:<br> +><br> +>> Tail-call execution semantics require "unclean stake" , = +i.e. final<br> +>> stake with more than one item. However, "unclean stake" = +is invalid<br> +>> (not just non-standard) in BIP141, so you could only use it with<b= +r> +>> legacy P2SH (which is totally pointless....). A different design<b= +r> +>> like OP_EVAL might be needed, or you need a new witness script<br> +>> version.<br> +><br> +> I believe you meant "unclean stack," and you are correct. Th= +is was<br> +> also pointed out last tuesday by a participant at the in-person<br> +> CoreDev meetup where the idea was presented.<br> +><br> +> This doesn't kill the idea, it just complicates the implementation= +<br> +> slightly. A simple fix would be to allow tail-recursion to occur if<br= +> +> the stack is not clean (as can happen with legacy P2SH as you point<br= +> +> out, or yet to be defined version 1+ forms of segwit script), OR if<br= +> +> there is a single item on the stack and the alt-stack is not empty.<br= +> +> For segwit v0 scripts you then have to move any arguments to the alt<b= +r> +> stack before ending the redeem script, leaving just the policy script<= +br> +> 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> +><br> +>> I think you have also missed the sigOp counting of the executed<br= +> +>> script. As you can't count it without executing the script, th= +e<br> +>> 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<br> +>> precise outcome of script execution (instead of just pass or fail)= +,<br> +>> which is a layer violation.<br> +><br> +> I disagree with this design requirement.<br> +><br> +> The SigOp counting method used by bitcoin is flawed. It incorrectly<br= +> +> limits not the number of signature operations necessary to validate a<= +br> +> block, but rather the number of CHECKSIGs potentially encountered in<b= +r> +> script execution, even if in an unexecuted branch. (Admitedly MAST<br> +> makes this less of an issue, but there are still useful compact<br> +> scripts that use if/else constructs to elide a CHECKSIG.) Nor will it<= +br> +> account for aggregation when that feature is added, or properly<br> +> differentiate between signature operations that can be batched and<br> +> those that can not.<br> +><br> +> Additionally there are other resources used by script that should be<b= +r> +> globally limited, such as hash operations, which are not accounted for= +<br> +> at this time and cannot be statically assessed, even by the flawed<br> +> mechanism by which SigOps are counted. I have maintained for some time= +<br> +> that bitcoin should move from having multiple separate global limits<b= +r> +> (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear= +<br> +> metric that combines all of these factors with appropriate<br> +> coefficients.<br> +><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> +> A better way of handling this problem, which works for both SigOps and= +<br> +> HashOps, is to have the witness commit to the maximum resources<br> +> consumed by validation of the spend of the coin, to relay this data<br= +> +> with the transaction and include it in the SigHash, and to use the<br> +> committed maximum for block validation. This could be added in a<br> +> future script version upgrade. This change would also resolve the<br> +> issue that led to the clean stack rule in segwit, allowing future<br> +> versions of script to use tail-call recursion without involving the<br= +> +> alt-stack.<br> +><br> +> Nevertheless it is constructive feedback that the current draft of the= +<br> +> BIP and its implementation do not count SigOps, at all. There are a<br= +> +> couple of ways this can be fixed by evaluating the top-level script<br= +> +> and then doing static analysis of the resulting policy script, or by<b= +r> +> 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> +><br> +> Additionally, it is possible that we take this time to re-evaluate<br> +> whether we should be counting SigOps other than for legacy consensus<b= +r> +> rule compliance. The speed of verification in secp256k1 has made<br> +> signature operations no longer the chief concern in block validation<b= +r> +> times.<br> +<br> +Without the limit I think we would be DoS-ed to dead<br> +<br> +<br> +>> Witness script versioning is by design fully compatible with P2SH<= +br> +>> and BIP173, so there will be no hurdle for existing wallets to pay= +<br> +>> to BIP114. Actually it should be completely transparent to them.<b= +r> +><br> +> This is correct. Your feedback will be incorporated.<br> +><br> +>> For code complexity, the minimal BIP114 could be really simple, li= +ke<br> +>> <30 lines of code? It looks complex now because it does much mo= +re<br> +>> than simply hiding scripts in a hash.<br> +><br> +> Is there a repo that contains the latest implementation of BIP 114,<br= +> +> 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> +><br> +> Kind regards,<br> +> Mark Friedenbach<br> +><br> +<br> +<br> +<br> +<br> +------------------------------<br> +<br> +Message: 2<br> +Date: Tue, 12 Sep 2017 11:06:15 +0200<br> +From: Thomas Voegtlin <<a href=3D"mailto:thomasv@electrum.org">thomasv@e= +lectrum.org</a>><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: <<a href=3D"mailto:99643f72-f72f-e4e9-ac2b-72bf519c25b5@elec= +trum.org">99643f72-f72f-e4e9-ac2b-<wbr>72bf519c25b5@electrum.org</a>><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> +> Hi,<br> +><br> +> I understand the motivation of adding the birthdate field. However, no= +t<br> +> very comfortable with having this in the public key serialization. The= +re<br> +> are privacy implication of both the birthday field and having the comp= +lete<br> +> derivation path, which takes space.<br> +> > I am fine with Thomas proposal of {x,y,z}. Having additional vers= +ion byte<br> +> field looks modular but since since we already have the big enough ver= +sion<br> +> field in bip32, better to use that instead of adding more bytes.<br> +><br> +> Thomas, can you please explain why we require different version for P2= +WPKH<br> +> or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that= + they<br> +> 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> +><br> +> On Fri, Sep 8, 2017 at 2:09 AM, <<br> +> <a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitco= +in-dev-request@lists.<wbr>linuxfoundation.org</a>> wrote:<br> +><br> +>> Send bitcoin-dev mailing list submissions to<br> +>>=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> +>><br> +>> To subscribe or unsubscribe via the World Wide Web, visit<br> +>>=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> +>> or, via email, send a message with subject or body 'help' = +to<br> +>>=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> +>><br> +>> You can reach the person managing the list at<br> +>>=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> +>><br> +>> When replying, please edit your Subject line so it is more specifi= +c<br> +>> than "Re: Contents of bitcoin-dev digest..."<br> +>><br> +>><br> +>> Today's Topics:<br> +>><br> +>>=C2=A0 =C2=A0 1. Re: Proposal: Extended serialization format for=C2= +=A0 =C2=A0BIP-32<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Andreas Schildbach)<br> +>>=C2=A0 =C2=A0 2. Re: Proposal: Extended serialization format for BI= +P-32<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Pavol Rusnak)<br> +>>=C2=A0 =C2=A0 3. Re: Fast Merkle Trees (Mark Friedenbach)<br> +>>=C2=A0 =C2=A0 4. Re: Proposal: Extended serialization format for BI= +P-32<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wallets (Thomas Voegtlin)<br> +>><br> +>><br> +>> ------------------------------<wbr>------------------------------<= +wbr>----------<br> +>><br> +>> Message: 1<br> +>> Date: Thu, 7 Sep 2017 21:35:49 +0200<br> +>> From: Andreas Schildbach <<a href=3D"mailto:andreas@schildbach.= +de">andreas@schildbach.de</a>><br> +>> To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= +in-dev@lists.<wbr>linuxfoundation.org</a><br> +>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= + for<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br> +>> Message-ID: <oos72e$rjp$<a href=3D"mailto:1@blaine.gmane.org">1= +@blaine.gmane.org</a><wbr>><br> +>> Content-Type: text/plain; charset=3Dutf-8<br> +>><br> +>> On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:<br> +>>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:<br> +>>>> A solution is still needed to wallets who do not wish to u= +se BIP43<br> +>>><br> +>>> What if we added another byte field OutputType for wallets tha= +t do not<br> +>>> follow BIP43?<br> +>>><br> +>>> 0x00 - P2PKH output type<br> +>>> 0x01 - P2WPKH-in-P2SH output type<br> +>>> 0x02 - native Segwit output type<br> +>>><br> +>>> Would that work for you?<br> +>><br> +>> I think that would work.<br> +>><br> +>>> The question is whether this field should be present only if d= +epth=3D=3D0x00<br> +>>> or at all times. What is your suggestion, Thomas?<br> +>><br> +>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) = +and still<br> +>> we need this field. I think it should always be present if a chain= + is<br> +>> limited to a certain script type.<br> +>><br> +>> There is however the case where even on one chain, script types ar= +e<br> +>> mixed. In this case the field should be omitted and the wallet nee= +ds to<br> +>> scan for all (known) types. Afaik Bitcoin Core is taking this path= +.<br> +>><br> +>><br> +>><br> +>> ------------------------------<br> +>><br> +>> Message: 2<br> +>> Date: Thu, 7 Sep 2017 22:00:05 +0200<br> +>> From: Pavol Rusnak <<a href=3D"mailto:stick@satoshilabs.com">st= +ick@satoshilabs.com</a>><br> +>> To: Andreas Schildbach <<a href=3D"mailto:andreas@schildbach.de= +">andreas@schildbach.de</a>>, Bitcoin Protocol<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discussion <<a href=3D"mailto:= +bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundati= +on.org</a>><br> +>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= + for<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br> +>> Message-ID: <<a href=3D"mailto:40ed03a1-915c-33b0-c4ac-e898c8c7= +33ba@satoshilabs.com">40ed03a1-915c-33b0-c4ac-<wbr>e898c8c733ba@satoshilabs= +.com</a>><br> +>> Content-Type: text/plain; charset=3Dwindows-1252<br> +>><br> +>> On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:<br> +>>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,= +1]) and still<br> +>>> we need this field.<br> +>><br> +>> But the depth of exported public key will be null. It does not mak= +e<br> +>> sense to export xpub for m or m/0' for your particular case.<b= +r> +>><br> +>>> I think it should always be present if a chain is<br> +>>> limited to a certain script type.<br> +>><br> +>> I am fine with having the path there all the time.<br> +>><br> +>>> There is however the case where even on one chain, script type= +s are<br> +>>> mixed. In this case the field should be omitted and the wallet= + needs to<br> +>>> scan for all (known) types. Afaik Bitcoin Core is taking this = +path.<br> +>><br> +>> Is that really the case? Why come up with a hierarchy and then don= +'t use<br> +>> it?<br> +>><br> +>> --<br> +>> Best Regards / S pozdravom,<br> +>><br> +>> Pavol "stick" Rusnak<br> +>> CTO, SatoshiLabs<br> +>><br> +>><br> +>> ------------------------------<br> +>><br> +>> Message: 3<br> +>> Date: Thu, 7 Sep 2017 13:04:30 -0700<br> +>> From: Mark Friedenbach <<a href=3D"mailto:mark@friedenbach.org"= +>mark@friedenbach.org</a>><br> +>> To: Russell O'Connor <<a href=3D"mailto:roconnor@blockstrea= +m.io">roconnor@blockstream.io</a>><br> +>> Cc: Bitcoin Protocol Discussion<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:bitcoin-dev= +@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&= +gt;<br> +>> Subject: Re: [bitcoin-dev] Fast Merkle Trees<br> +>> Message-ID: <<a href=3D"mailto:40D6F502-3380-4B64-BCD9-80D361EE= +D35C@friedenbach.org">40D6F502-3380-4B64-BCD9-<wbr>80D361EED35C@friedenbach= +.org</a>><br> +>> Content-Type: text/plain; charset=3D"us-ascii"<br> +>><br> +>> TL;DR I'll be updating the fast Merkle-tree spec to use a diff= +erent<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0IV, using (for infrastructure compatabil= +ity reasons) the scheme<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by Peter Todd.<br> +>><br> +>> 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<br> +>> the same sort of problem when doing key aggregation, in which you = +must<br> +>> require the other party to prove knowledge of the discrete log bef= +ore<br> +>> using their public key, or else key cancellation can occur.<br> +>><br> +>> 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<br> +>> of DL knowledge (signatures), but the basic idea is the same. Mult= +i-<br> +>> party wallet level protocols for jointly constructing scriptPubKey= +s<br> +>> should require a 'delinearization' step that proves knowle= +dge of<br> +>> information necessary to complete each part of the script, as part= + of<br> +>> proving the safety of a construct.<br> +>><br> +>> I think my hangup before in understanding the attack you describe = +was<br> +>> in actualizing it into a practical attack that actually escalates = +the<br> +>> attacker's capabilities. If the attacker can get you to agree = +to a<br> +>> MAST policy that is nothing more than a CHECKSIG over a key they<b= +r> +>> presumably control, then they don't need to do any complicated= +<br> +>> grinding. The attacker in that scenario would just actually specif= +y a<br> +>> key they control and take the funds that way.<br> +>><br> +>> Where this presumably leads to an actual exploit is when you speci= +fy a<br> +>> script that a curious counter-party actually takes the time to<br> +>> investigate and believes to be secure. For example, a script that<= +br> +>> requires a signature or pre-image revelation from that counter-par= +ty.<br> +>> 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.<b= +r> +>><br> +>> If I understand the revised attack description correctly, then the= +re<br> +>> is a small window in which the attacker can create a script less t= +han<br> +>> 55 bytes in length, where nearly all of the first 32 bytes are<br> +>> selected by the attacker, yet nevertheless the script seems safe t= +o<br> +>> the counter-party. The smallest such script I was able to construc= +t<br> +>> was the following:<br> +>><br> +>>=C2=A0 =C2=A0 =C2=A0<fake-pubkey> CHECKSIGVERIFY HASH160 <= +preimage> EQUAL<br> +>><br> +>> 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<br> +>> 32-byte pubkeys (in a script version upgrade, for example) would<b= +r> +>> reduce this to the necessary 55 bytes with 0 bits of grinding. A<b= +r> +>> smaller variant is possible:<br> +>><br> +>>=C2=A0 =C2=A0 =C2=A0DUP HASH160 <fake-pubkey-hash> EQUALVERIF= +Y CHECKSIGVERIFY HASH160<br> +>> <preimage> EQUAL<br> +>><br> +>> This is 46 bytes, but requires grinding 96 bits, which is a bit le= +ss<br> +>> plausible.<br> +>><br> +>> 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<br> +>> the scheme to use a different IV for hash tree updates. This would= +<br> +>> prevent even the above implausible attacks.<br> +>><br> +>><br> +>>> On Sep 7, 2017, at 11:55 AM, Russell O'Connor <<a href= +=3D"mailto:roconnor@blockstream.io">roconnor@blockstream.io</a>><br> +>> wrote:<br> +>>><br> +>>><br> +>>><br> +>>> On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach <<a href= +=3D"mailto:mark@friedenbach.org">mark@friedenbach.org</a><br> +>> <mailto:<a href=3D"mailto:mark@friedenbach.org">mark@friedenbac= +h.org</a>>> wrote:<br> +>>> I've been puzzling over your email since receiving it. I&#= +39;m not sure it<br> +>>> is possible to perform the attack you describe with the tree s= +tructure<br> +>>> specified in the BIP. If I may rephrase your attack, I believe= + you are<br> +>>> seeking a solution to the following:<br> +>>><br> +>>> Want: An innocuous script and a malign script for which<br> +>>><br> +>>>=C2=A0 =C2=A0 double-SHA256(innocuous)<br> +>>><br> +>>> is equal to either<br> +>>><br> +>>>=C2=A0 =C2=A0 fast-SHA256(double-SHA256(<wbr>malign) || r) or<b= +r> +>>>=C2=A0 =C2=A0 fast-SHA256(r || double-SHA256(malign))<br> +>>><br> +>>> or=C2=A0 fast-SHA256(fast-SHA256(<wbr>double-SHA256(malign) ||= + r1) || r0)<br> +>>> or=C2=A0 fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) = +|| r0)<br> +>>> or ...<br> +>>><br> +>>> where r is a freely chosen 32-byte nonce. This would allow the= +<br> +>>> attacker to reveal the innocuous script before funds are sent = +to the<br> +>>> MAST, then use the malign script to spend.<br> +>>><br> +>>> Because of the double-SHA256 construction I do not see how thi= +s can be<br> +>>> accomplished without a full break of SHA256.<br> +>>><br> +>>> The particular scenario I'm imagining is a collision betwe= +en<br> +>>><br> +>>>=C2=A0 =C2=A0 =C2=A0double-SHA256(innocuous)<br> +>>><br> +>>> and<br> +>>><br> +>>>=C2=A0 =C2=A0 =C2=A0fast-SHA256(fast-SHA256(fast-<wbr>SHA256(do= +uble-SHA256(malign) || r2) ||<br> +>> r1) || r0).<br> +>>><br> +>>> where innocuous is a Bitcoin Script that is between 32 and 55 = +bytes long.<br> +>>><br> +>>> Observe that when data is less than 55 bytes then double-SHA25= +6(data) =3D<br> +>> fast-SHA256(fast-SHA256(<wbr>padding-SHA256(data)) || 0x8000...100= +) (which is<br> +>> really the crux of the matter).<br> +>>><br> +>>> Therefore, to get our collision it suffices to find a collisio= +n between<br> +>>><br> +>>>=C2=A0 =C2=A0 =C2=A0padding-SHA256(innocuous)<br> +>>><br> +>>> and<br> +>>><br> +>>>=C2=A0 =C2=A0 =C2=A0fast-SHA256(double-SHA256(<wbr>malign) || r= +2) || r1<br> +>>><br> +>>> r1 can freely be set to the second half of padding-SHA256(inno= +cuous), so<br> +>> it suffices to find a collision between<br> +>>><br> +>>>=C2=A0 =C2=A0 fast-SHA256(double-SHA256(<wbr>malign) || r2)<br> +>>><br> +>>> and the first half of padding-SHA256(innocuous) which is equal= + to the<br> +>> first 32 bytes of innocuous.<br> +>>><br> +>>> Imagine the first opcode of innocuous is the push of a value t= +hat the<br> +>> attacker claims to be his 33-byte public key.<br> +>>> So long as the attacker doesn't need to prove that they kn= +ow the<br> +>> discrete log of this pubkey, they can grind r2 until the result of= +<br> +>> fast-SHA256(double-SHA256(<wbr>malign) || r2) contains the correct= + first<br> +>> couple of bytes for the script header and the opcode for a 33-byte= + push.=C2=A0 I<br> +>> believe that is only about 3 or 4 bytes of they need to grind out.= +<br> +>>><br> +>><br> +>> -------------- next part --------------<br> +>> An HTML attachment was scrubbed...<br> +>> URL: <<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> +>> attachments/20170907/63af0292/<wbr>attachment-0001.html><br> +>><br> +>> ------------------------------<br> +>><br> +>> Message: 4<br> +>> Date: Thu, 7 Sep 2017 22:39:17 +0200<br> +>> From: Thomas Voegtlin <<a href=3D"mailto:thomasv@electrum.org">= +thomasv@electrum.org</a>><br> +>> To: "<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= +>bitcoin-dev@lists.<wbr>linuxfoundation.org</a>"<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:bitcoin-dev= +@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&= +gt;<br> +>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format= + for<br> +>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIP-32 wallets<br> +>> Message-ID: <<a href=3D"mailto:9e74dc17-105c-b43c-7780-4fa69004= +3fe2@electrum.org">9e74dc17-105c-b43c-7780-<wbr>4fa690043fe2@electrum.org</= +a>><br> +>> Content-Type: text/plain; charset=3Dwindows-1252<br> +>><br> +>><br> +>><br> +>> On 07.09.2017 18:23, Pavol Rusnak wrote:<br> +>>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:<br> +>>>> A solution is still needed to wallets who do not wish to u= +se BIP43<br> +>>><br> +>>> What if we added another byte field OutputType for wallets tha= +t do not<br> +>>> follow BIP43?<br> +>>><br> +>>> 0x00 - P2PKH output type<br> +>>> 0x01 - P2WPKH-in-P2SH output type<br> +>>> 0x02 - native Segwit output type<br> +>>><br> +>>> Would that work for you?<br> +>>><br> +>>> The question is whether this field should be present only if d= +epth=3D=3D0x00<br> +>>> or at all times. What is your suggestion, Thomas?<br> +>>><br> +>><br> +>><br> +>> well, in my initial proposal, I wrote that this value should be us= +er<br> +>> visible. That is why I used version bytes. If you create an extra = +byte<br> +>> field, and then use base58 or bech32 encoding, the value will not = +be<br> +>> user visible anymore.<br> +>><br> +>> The initial implementation of segwit xpub/xprv in Electrum used a = +flag<br> +>> that was not user visible (I added 1 to the bip32 version bytes, w= +hich<br> +>> leaves the xpub/xprv prefix unchanged). I have experimented with t= +hat<br> +>> invisible flag for more than 6 months now, and I am now convinced = +that<br> +>> it is better to make that flag user visible.<br> +>><br> +>> The reason is that when users create wallets with multisig scripts= +, they<br> +>> need to combine several master public keys. However, these master = +public<br> +>> keys should all be of the same type: it would not make sense to cr= +eate a<br> +>> 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<br> +>> cosigners agree on the script type that will be used to derive add= +resses.<br> +>><br> +>> In other words, if users are exposed to master keys and need to<br= +> +>> manipulate them, it is better to let them see what they are doing.= +<br> +>><br> +>> OTOH if you do not plan to expose your users to these keys, you pr= +obably<br> +>> do not need a serialization format.<br> +>><br> +>><br> +>> ------------------------------<br> +>><br> +>> ______________________________<wbr>_________________<br> +>> bitcoin-dev mailing list<br> +>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= +ev@lists.<wbr>linuxfoundation.org</a><br> +>> <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> +>><br> +>><br> +>> End of bitcoin-dev Digest, Vol 28, Issue 17<br> +>> ******************************<wbr>*************<br> +>><br> +><br> +><br> +><br> +> ______________________________<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.<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.<wb= +r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +><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 <<a href=3D"mailto:sergio.d.lerner@gmail.com"= +>sergio.d.lerner@gmail.com</a>><br> +To: Anthony Towns <<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.a= +u</a>>,=C2=A0 Bitcoin Protocol Discussion<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= +undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>><br> +Subject: Re: [bitcoin-dev] Responsible disclosure of bugs<br> +Message-ID:<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:CAKzdR-oYQ8EchpJVE56yJbfB= +gNHihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.com">CAKzdR-<wbr>oYQ8EchpJVE56yJbfBgN= +Hihx7WO_<wbr>gtFtp6QKOcK7uT-w@mail.gmail.<wbr>com</a>><br> +Content-Type: text/plain; charset=3D"utf-8"<br> +<br> +Historically people have published vulnerabilities in Bitcoin only after<br= +> +>80% of the nodes have upgraded. This seems to be the general (but not<b= +r> +publicly stated) policy. If you'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 "natural" 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 <<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a>> wrote:<br> +<br> +> On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:<br> +> > I don't think I know the right answer here, but I will point = +out two<br> +> things<br> +> > that make this a little more complicated.<br> +> > 1 - There are lots of altcoin developers and while I'm sure t= +he majority<br> +> would<br> +> > greatly appreciate the disclosure and would behave responsibly wi= +th the<br> +> > information, I don't know where you draw the line on who you = +tell and<br> +> who you<br> +> > don't.<br> +><br> +> If you can't pick even a small group that's trustworthy (top f= +ive by<br> +> market cap as a start [0]? or just major bitcoin wallets / exchanges /= +<br> +> alt node implementations?), then it still seems better to (eventually)= +<br> +> 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<br> +> reasons?<br> +><br> +> I find it hard to imagine bitcoin's still obscure enough that peop= +le<br> +> aren't tracking git commit logs to use them as inspiration for att= +acks<br> +> on bitcoin users and businesses; at best I would have thought it'd= +<br> +> 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<br= +> +> 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)<br> +><br> +> > 2- Unlike other software, I'm not sure good security for bitc= +oin is<br> +> defined by<br> +> > constant upgrading.=C2=A0 Obviously upgrading has an important be= +nefit, but<br> +> one of<br> +> > the security considerations for Bitcoin is knowing that your defi= +nition<br> +> of the<br> +> > money hasn't changed.=C2=A0 Much harder to know that if you c= +hange software.<br> +><br> +> Isn't that just an argument for putting more effort into backporti= +ng<br> +> fixes/workarounds? (I don't see how you do that without essentiall= +y<br> +> publically disclosing which patches have a security impact -- "oh= +,<br> +> gosh, this patch gets a backport, I wonder if maybe it has security<br= +> +> implications...")<br> +><br> +> (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<br> +> security, even if you don't upgrade; "herd immunity" if = +you will. That<br> +> 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<br> +> upgrading at all)<br> +><br> +> If altcoin maintainers are inconvenienced by tracking bitcoin-core<br> +> updates, that would be an argument for them to contribute back to thei= +r<br> +> upstream to make their own job easier; either helping with backports,<= +br> +> or perhaps contributing to patches like PR#8994 might help.<br> +><br> +> All of those things seem like they'd help not just altcoins but bi= +tcoin<br> +> investors/traders too, so it's not even a trade-off between classe= +s of<br> +> bitcoin core users.=C2=A0 And if in the end various altcoins aren'= +t able to<br> +> keep up with security fixes, that's probably valuable information = +to<br> +> provide to the market...<br> +><br> +> Cheers,<br> +> aj<br> +><br> +> [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?<br> +>=C2=A0 =C2=A0 =C2=A0I've no idea which of those might have trustwor= +thy devs to work with,<br> +>=C2=A0 =C2=A0 =C2=A0but surely at least a couple do?<br> +><br> +> ______________________________<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.<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.<wb= +r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +><br> +-------------- next part --------------<br> +An HTML attachment was scrubbed...<br> +URL: <<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>><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-- + |