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 > ******************************************* >