diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2015-11-08 14:54:04 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-08 14:54:08 +0000 |
| commit | 8b2ad51d13e1005b0df58e633bd747c791c18ef9 (patch) | |
| tree | 12205c3eb4ff8366a831657ccc440eabdd46ed44 | |
| parent | 1354c4b8c63baea4bad927505244176b4c80ca1c (diff) | |
| download | pi-bitcoindev-8b2ad51d13e1005b0df58e633bd747c791c18ef9.tar.gz pi-bitcoindev-8b2ad51d13e1005b0df58e633bd747c791c18ef9.zip | |
Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
| -rw-r--r-- | a0/138e5c18a9d83ad2e0d45b78cfcf99f6926a94 | 449 |
1 files changed, 449 insertions, 0 deletions
diff --git a/a0/138e5c18a9d83ad2e0d45b78cfcf99f6926a94 b/a0/138e5c18a9d83ad2e0d45b78cfcf99f6926a94 new file mode 100644 index 000000000..3a387be56 --- /dev/null +++ b/a0/138e5c18a9d83ad2e0d45b78cfcf99f6926a94 @@ -0,0 +1,449 @@ +Return-Path: <gavinandresen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 0EF1F8EF + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 8 Nov 2015 14:54:08 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com + [209.85.215.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30D52151 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 8 Nov 2015 14:54:06 +0000 (UTC) +Received: by lffz63 with SMTP id z63so21598351lff.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 08 Nov 2015 06:54:04 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=+GBGyqvrWHIZPCx8wQaaJ8vCyTxSzDRo2rOG5XlqVSM=; + b=muQMLrvWgivuwq/Wcm6pV9yr5tFDl+cRZ0hhO1QWDR/z3sGw4uoaJXe4CSV2lbQR3f + EA9JqGQm3MO8RiK6MjdiQJma9OzUYlZiUrjy8+Z4p0MWiLzU9PUB1N/LkdiqnQKZKFwr + HWOfnVhWnZPxK78cNH1vIGxbH+4kKj0LxM9BSiZyRy88yZWSsOkUI7u5ecZeJz4CnRCK + rG0vxL1d8sW5vlV8Gyy+P7HtXqBFfloNO0ICTaBXBpRj0k3TKgE+hek5W9ar4S2HtHF2 + 7CFhOML+rnhBIL/J0Rxv6pnHzAg9RNtnwYC0n5w62azsH/Zd1IDZSw9lAyShbqXJ3BJA + 8I4g== +MIME-Version: 1.0 +X-Received: by 10.25.154.203 with SMTP id c194mr7507962lfe.32.1446994444177; + Sun, 08 Nov 2015 06:54:04 -0800 (PST) +Received: by 10.25.22.95 with HTTP; Sun, 8 Nov 2015 06:54:04 -0800 (PST) +In-Reply-To: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com> +References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com> +Date: Sun, 8 Nov 2015 14:54:04 +0000 +Message-ID: <CABsx9T0T6QuYRmNyF_F124GyQ2EX5w93HCPLvrd4L5P6=xj_Xw@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: Adam Back <adam@cypherspace.org> +Content-Type: multipart/alternative; boundary=001a11401604d6589b052408a545 +X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Sun, 08 Nov 2015 14:54:08 -0000 + +--001a11401604d6589b052408a545 +Content-Type: text/plain; charset=UTF-8 + +On Thu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Some thoughts, hope this is not off-topic. +> +> Maybe we should summarise the security assumptions and design +> requirements. It is often easier to have clear design discussions by +> first articulating assumptions and requirements. +> +> Validators: Economically dependent full nodes are an important part of +> Bitcoin's security model because they assure Bitcoin security by +> enforcing consensus rules. While full nodes do not have orphan +> risk, we also dont want maliciously crafted blocks with pathological +> validation cost to erode security by knocking reasonable spec full +> nodes off the network on CPU (or bandwidth grounds). +> + +Agreed. That is why BIP101 / BitcoinXT includes code to limit the relay and +validation cost of blocks. + + +> +> Miners: Miners are in a commodity economics competitive environment +> where various types of attacks and collusion, even with small +> advantage, may see actual use due to the advantage being significant +> relative to the at times low profit margin +> + +Agreed, with a quibble: mining economics means they will ALWAYS have a low +profit margin. + + +> +> It is quite important for bitcoin decentralisation security that small +> miners not be significantly disadvantaged vs large miners. Similarly +> it is important that there not be significant collusion advantages +> that create policy centralisation as a side-effect (for example what +> happened with "SPV mining" or validationless mining during BIP66 +> deployment). Examples of attacks include selfish-mining and +> amplifying that kind of attack via artificially large or +> pathologically expensive to validate blocks. Or elevating orphan risk +> for others (a miner or collusion of miners is not at orphan risk for a +> block they created). +> + +Okey dokey-- perhaps we should have another discussion about SPV mining, as +far as I know it harmed nobody besides the miners who mindlessly created +invalid, empty blocks (well, and besides being very annoying for developers +who had to figure out what was happening and get the offending miners to do +the right thing). + +In any case, it seems to me all of this (except perhaps selfish mining) is +independent of the maximum block size, and solutions for all of the above +(including selfish mining) should be pursued regardless of what is done +with the max block size (e.g. I sent Ittay and Gun email a few minutes ago +with some might-be-wong-ideas for how weak block announcements might be +used to detect selfish mining). + + +> +> Validators vs Miner decentralisation balance: +> +> There is a tradeoff where we can tolerate weak miner decentralisation +> if we can rely on good validator decentralisation or vice versa. But +> both being weak is risky. Currently given mining centralisation +> itself is weak, that makes validator decentralisation a critical +> remaining defence - ie security depends more on validator +> decentralisation than it would if mining decentralisation was in a +> better shape. +> + +I'm very disappointed you don't mention the tradeoff at "the other end of +the bathtub" -- Key-holder versus Validator decentralization balance. Did +you see the excellent Poon/Dryja "bathtub" presentation at Montreal? + +https://scalingbitcoin.org/montreal2015/presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf + +Security: +> +> We should consider the pathological case not average or default behaviour +> because we can not assume people will follow the defaults, only the +> consensus-enforced rules. +> + +Agreed, which is why BIP101/XT consider pathological behavior. + + +> +> We should not discount attacks that have not seen exploitation to +> date. We have maybe benefitted from universal good-will (everybody +> thinks Bitcoin is cool, particularly people with skills to find and +> exploit attacks). +> + +Disagree on wording: we should not ignore attacks that have not seen +exploitation. But in the never-ending-list of things to be worried about +and to write code for, attacks that have not been seen should be lower +priority than attacks that have been seen, either in Bitcoin or elsewhere. + +E.g. Bitcoin has never seen a buffer-overflow attack, but we absolutely +positively need to put a very high priority on the network attack surface +-- we know buffer-overflow attacks are commonly exploited. + +On the other hand, Bitcoin has never seen a "Goldfinger attack" (take a big +short position on Bitcoin, then find a way to destroy confidence so the +price drops and you can profit), and "Goldfinger attacks" don't seem to be +common anywhere (you don't see people taking huge short positions in +companies and then bombing their factories). There might be a reason +Bitcoin is more vulnerable, or the same checks-and-balances (e.g. whoever +took the other side of the large short has a strong incentive to report +you, and assuming you got paid in something other than Bitcoin that is +probably possible). + (Aside: anybody who wants to talk about the likelihood of "Goldfinger +attacks" please start a thread somewhere else, I don't think that's +appropriate for bitcoin-dev). + + +> +> We can consider a hierarchy of defences most secure to least: +> +> 1. consensus rule enforced (attacker loses block reward) +> 2. economic alignment (attacker loses money) +> 3. overt (profitable, but overt attacks are less likely to be exploited) +> 4. meta-incentive (relying on meta-incentive to not damage the ecosystem +> only) +> + +Agreed. + + +> Best practices: +> +> We might want to list some best practices that are important for the +> health and security of the Bitcoin network. +> +> Rule of thumb KISS stuff: +> +> We should aim to keep things simple in general and to avoid creating +> complex optimisation problems for transaction processors, wallets, +> miners. +> + +I agree with KISS. + +I think we can't avoid creating complex optimization problems sometimes-- +see, for example, the difficulty of a wallet predicting what transaction +fee is needed for a transaction to get confirmed in X blocks (lots of +factors involved-- max block size, time since last block, miner policy as +expressed in previous blocks, transactions currently waiting in +mempool....). I do agree we should prefer simple optimization problems +over complex wherever we can. + + + +> We may want to consider an incremental approach (shorter-time frame or +> less technically ambitious) in the interests of simplifying and +> getting something easier to arrive at consensus, and thus faster to +> deploy. +> + +Or we may want to go with something that is already tested and deployed... + + +> +> We should not let the perfect be the enemy of the good. But we should +> not store new problems for the future, costs are stacked in favour of +> getting it right vs A/B testing on the live network. +> + +I disagree about "storing new problems for the future." We don't know what +the problems will be in the future, so there is alway a leap of faith that +future engineers will be smart enough to fix the engineering problems that +arise (see the worries over quantum computing advances making ECDSA +obsolete) -- ESPECIALLY if we have thumbnail sketches of solutions that +we're reasonably certain will work (e.g. switching to a quantum-resistant +signature algorithm via soft-fork). + + +> +> Not everything maybe fixable in one go for complexity reasons or for +> the reason that there is no clear solution for some issues. We should +> work incrementally. +> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> + + +I think the disagreement is how big a change fits into the definition of +"incrementally." + +As Jeff Garzik has pointed out, the recent change from "we never hit the +maximum block size limit" to "we regularly run into the maximum block size +limit" was a large, NON-incremental change... + +-- +-- +Gavin Andresen + +--001a11401604d6589b052408a545 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= +hu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev <span dir=3D"ltr">&l= +t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank= +">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquot= +e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width= +:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef= +t:1ex">Some thoughts, hope this is not off-topic.<br> +<br> +Maybe we should summarise the security assumptions and design<br> +requirements.=C2=A0 It is often easier to have clear design discussions by<= +br> +first articulating assumptions and requirements.<br> +<br> +Validators: Economically dependent full nodes are an important part of<br> +Bitcoin's security model because they assure Bitcoin security by<br> +enforcing consensus rules.=C2=A0 While full nodes do not have orphan<br> +risk, we also dont want maliciously crafted blocks with pathological<br> +validation cost to erode security by knocking reasonable spec full<br> +nodes off the network on CPU (or bandwidth grounds).<br></blockquote><div><= +br></div><div>Agreed. That is why BIP101 / BitcoinXT includes code to limit= + the relay and validation cost of blocks.</div><div>=C2=A0</div><blockquote= + class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:= +1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left= +:1ex"> +<br> +Miners: Miners are in a commodity economics competitive environment<br> +where various types of attacks and collusion, even with small<br> +advantage, may see actual use due to the advantage being significant<br> +relative to the at times low profit margin<br></blockquote><div><br></div><= +div>Agreed, with a quibble: mining economics means they will ALWAYS have a = +low profit margin.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" = +style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r= +gb(204,204,204);border-left-style:solid;padding-left:1ex"> +<br> +It is quite important for bitcoin decentralisation security that small<br> +miners not be significantly disadvantaged vs large miners.=C2=A0 Similarly<= +br> +it is important that there not be significant collusion advantages<br> +that create policy centralisation as a side-effect (for example what<br> +happened with "SPV mining" or validationless mining during BIP66<= +br> +deployment).=C2=A0 Examples of attacks include selfish-mining and<br> +amplifying that kind of attack via artificially large or<br> +pathologically expensive to validate blocks.=C2=A0 Or elevating orphan risk= +<br> +for others (a miner or collusion of miners is not at orphan risk for a<br> +block they created).<br></blockquote><div><br></div><div>Okey dokey-- perha= +ps we should have another discussion about SPV mining, as far as I know it = +harmed nobody besides the miners who mindlessly created invalid, empty bloc= +ks (well, and besides being very annoying for developers who had to figure = +out what was happening and get the offending miners to do the right thing).= +</div><div><br></div><div>In any case, it seems to me all of this (except p= +erhaps selfish mining) is independent of the maximum block size, and soluti= +ons for all of the above (including selfish mining) should be pursued regar= +dless of what is done with the max block size (e.g. I sent Ittay and Gun em= +ail a few minutes ago with some might-be-wong-ideas for how weak block anno= +uncements might be used to detect selfish mining).=C2=A0</div><div>=C2=A0</= +div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= +der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol= +id;padding-left:1ex"> +<br> +Validators vs Miner decentralisation balance:<br> +<br> +There is a tradeoff where we can tolerate weak miner decentralisation<br> +if we can rely on good validator decentralisation or vice versa.=C2=A0 But<= +br> +both being weak is risky.=C2=A0 Currently given mining centralisation<br> +itself is weak, that makes validator decentralisation a critical<br> +remaining defence - ie security depends more on validator<br> +decentralisation than it would if mining decentralisation was in a<br> +better shape.<br></blockquote><div><br></div><div>I'm very disappointed= + you don't mention the tradeoff at "the other end of the bathtub&q= +uot; -- Key-holder versus Validator decentralization balance. Did you see t= +he excellent Poon/Dryja "bathtub" presentation at Montreal?</div>= +<div>=C2=A0 =C2=A0=C2=A0<a href=3D"https://scalingbitcoin.org/montreal2015/= +presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf">https://scalingbitcoin= +.org/montreal2015/presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf</a></= +div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= +x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border= +-left-style:solid;padding-left:1ex"> +Security:<br> +<br> +We should consider the pathological case not average or default behaviour<b= +r> +because we can not assume people will follow the defaults, only the<br> +consensus-enforced rules.<br></blockquote><div><br></div><div>Agreed, which= + is why BIP101/XT consider pathological behavior.</div><div>=C2=A0</div><bl= +ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= +t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= +ing-left:1ex"> +<br> +We should not discount attacks that have not seen exploitation to<br> +date.=C2=A0 We have maybe benefitted from universal good-will (everybody<br= +> +thinks Bitcoin is cool, particularly people with skills to find and<br> +exploit attacks).<br></blockquote><div><br></div><div>Disagree on wording: = +we should not ignore attacks that have not seen exploitation. But in the ne= +ver-ending-list of things to be worried about and to write code for, attack= +s that have not been seen should be lower priority than attacks that have b= +een seen, either in Bitcoin or elsewhere.</div><div><br></div><div>E.g. Bit= +coin has never seen a buffer-overflow attack, but we absolutely positively = +need to put a very high priority on the network attack surface -- we know b= +uffer-overflow attacks are commonly exploited.</div><div><br></div><div>On = +the other hand, Bitcoin has never seen a "Goldfinger attack" (tak= +e a big short position on Bitcoin, then find a way to destroy confidence so= + the price drops and you can profit), and "Goldfinger attacks" do= +n't seem to be common anywhere (you don't see people taking huge sh= +ort positions in companies and then bombing their factories). There might b= +e a reason Bitcoin is more vulnerable, or the same checks-and-balances (e.g= +. whoever took the other side of the large short has a strong incentive to = +report you, and assuming you got paid in something other than Bitcoin that = +is probably possible).</div><div>=C2=A0 (Aside: anybody who wants to talk a= +bout the likelihood of "Goldfinger attacks" please start a thread= + somewhere else, I don't think that's appropriate for bitcoin-dev).= +</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo= +rder-left-style:solid;padding-left:1ex"> +<br> +We can consider a hierarchy of defences most secure to least:<br> +<br> +1. consensus rule enforced (attacker loses block reward)<br> +2. economic alignment (attacker loses money)<br> +3. overt (profitable, but overt attacks are less likely to be exploited)<br= +> +4. meta-incentive (relying on meta-incentive to not damage the ecosystem on= +ly)<br></blockquote><div><br></div><div>Agreed.</div><div>=C2=A0</div><bloc= +kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-= +width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin= +g-left:1ex"> +Best practices:<br> +<br> +We might want to list some best practices that are important for the<br> +health and security of the Bitcoin network.<br> +<br> +Rule of thumb KISS stuff:<br> +<br> +We should aim to keep things simple in general and to avoid creating<br> +complex optimisation problems for transaction processors, wallets,<br> +miners.<br></blockquote><div><br></div><div>I agree with KISS.</div><div><b= +r></div><div>I think we can't avoid creating complex optimization probl= +ems sometimes-- see, for example, the difficulty of a wallet predicting wha= +t transaction fee is needed for a transaction to get confirmed in X blocks = +(lots of factors involved-- max block size, time since last block, miner po= +licy as expressed in previous blocks, transactions currently waiting in mem= +pool....).=C2=A0 I do agree we should prefer simple optimization problems o= +ver complex wherever we can.</div><div><br></div><div>=C2=A0</div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt= +h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le= +ft:1ex"> +We may want to consider an incremental approach (shorter-time frame or<br> +less technically ambitious) in the interests of simplifying and<br> +getting something easier to arrive at consensus, and thus faster to<br> +deploy.<br></blockquote><div><br></div><div>Or we may want to go with somet= +hing that is already tested and deployed...</div><div>=C2=A0</div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt= +h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le= +ft:1ex"> +<br> +We should not let the perfect be the enemy of the good.=C2=A0 But we should= +<br> +not store new problems for the future, costs are stacked in favour of<br> +getting it right vs A/B testing on the live network.<br></blockquote><div><= +br></div><div>I disagree about "storing new problems for the future.&q= +uot; =C2=A0We don't know what the problems will be in the future, so th= +ere is alway a leap of faith that future engineers will be smart enough to = +fix the engineering problems that arise (see the worries over quantum compu= +ting advances making ECDSA obsolete) -- ESPECIALLY if we have thumbnail ske= +tches of solutions that we're reasonably certain will work (e.g. switch= +ing to a quantum-resistant signature algorithm via soft-fork).</div><div>= +=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= +.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s= +tyle:solid;padding-left:1ex"> +<br> +Not everything maybe fixable in one go for complexity reasons or for<br> +the reason that there is no clear solution for some issues.=C2=A0 We should= +<br> +work incrementally.<br><a href=3D"https://lists.linuxfoundation.org/mailman= +/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank"></a></blockquot= +e></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I t= +hink the disagreement is how big a change fits into the definition of "= +;incrementally."</div><div class=3D"gmail_extra"><br></div><div class= +=3D"gmail_extra">As Jeff Garzik has pointed out, the recent change from &qu= +ot;we never hit the maximum block size limit" to "we regularly ru= +n into the maximum block size limit" was a large, NON-incremental chan= +ge...</div><div class=3D"gmail_extra"><br></div>-- <br><div>--<br>Gavin And= +resen<br></div><div><br></div> +</div></div> + +--001a11401604d6589b052408a545-- + |