From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 90E91C0051 for ; Thu, 1 Oct 2020 06:47:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 786DB86BAF for ; Thu, 1 Oct 2020 06:47:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHqSDHp+Bh63 for ; Thu, 1 Oct 2020 06:47:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by whitealder.osuosl.org (Postfix) with ESMTPS id E743C86BAD for ; Thu, 1 Oct 2020 06:47:07 +0000 (UTC) Date: Thu, 01 Oct 2020 06:47:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1601534824; bh=I+7vIlMY58+54vETBorDs8iO/Ju4r4/Z88+r6lkwpR4=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=bkEu25Czmdd8U8L3rpgvhsm0wps0aWkE/Ceeacv7z6B8eLpyDD7l5+vVoFmpTQ9GR WWGQ3Oghuwbh602YlmT02P9gC8XvDQAst5k0pcATYZUDD1Rppthyyipc4rDnipDQoH hBtG3BuNBBGDSMWIlyzy8wxSyTA3WIrndQCzz/sM= To: Mike Brooks , bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2WPSOr8E15WzoaUWtShu8zEjhDuSd1324drfNlZ1JW8nFgZNk9sBXeFc2nc_LYgmWZCcgThyZXumA8xbrEyny-xAHKyJiWxl9OP1pvsmG_U=@protonmail.com> In-Reply-To: References: <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com> <6DNfWVT6VsuQvFamBbqyGZYokENNopo28FZO6P5-4F0uoOMz2xAAQQZxBxsOmue4J3miOoMq_2MJVpiTtUy3bE9-qMOSVXqRhQoyfriTpXU=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 06:47:10 -0000 Good morning Mike, That is better than implied name-calling and refusing to lay out your argum= ent in detail. It is still sub-optimal since you are still being insulting by labeling me = as "reactionary", when you could have just laid out the exact same argument= ***in the first place*** without being unnecessarily inflammatory, but thi= s is significantly better than your previous behavior. I also strongly prefer to discuss this openly on the mailing list. > Consider for one moment when the words I=C2=A0have said are correct. Take= this moment=C2=A0to see the world from someone else's eyes, and do not be = reactionary - just be. > > Good. > > Consider a threat model, where nodes are unable to form new connections,= =C2=A0unless the attacker allows it to happen. The point of threat modeling= is not to question if it is possible, but rather to plan on failure becaus= e we live in a world where failure happens. Now if you are in a world of li= mited visibility, and a presented solution has no intrinsic=C2=A0value othe= r than it's length - then you create a node that is gullible.=C2=A0An adver= sary that controls=C2=A0connections can lie that a new solution was ever ev= en found or selectivally slow the formation of this side of the disagreemen= t, and probably other=C2=A0bad things too.=C2=A0 =C2=A0That sucks, and no o= ne is saying that there is a complete solution to this problem and we are a= ll here to help. > > You are absolutely=C2=A0correct - the eclipse effect is never going to be= perfect. Which is your point,=C2=A0and it's accurate. Imperfections in the= node's visibility=C2=A0allow for a more-fit=C2=A0solution=C2=A0to leak out= , and ultimately an identical consensus to form - so long as there is some = measure to judge the fitness of two disagreements of identical length. This is the point at which I think your argument fails. You are expecting: * That the attacker is powerful enough to split the network. * That the attacker is adept enough that it can split the network such that= mining hashpower is *exactly* split in half. * That the universe is in an eldritch state such that at the exact time one= side of the chain split finds a block, the other side of the chain split *= also* finds a block. This leads to a metastable state, where both chain splits have diverged and= yet are at the exact same block height, and it is true that this state can= be maintained indefinitely, with no 100% assurance it will disappear. Yet this is a [***metastable***](https://en.wikipedia.org/wiki/Metastabilit= y) state, as I have mentioned. Since block discovery is random, inevitably, even if the chain splits are e= xactly equal in mining hashpower, by random one or the other will win the n= ext block earlier than the other, precisely due to the random nature of min= ing, and if even a single direct connection were manually made between the = chain splits, this would collapse the losing chain split and it will be reo= rganized out without requiring floating-point Nakamoto. This is different if the coin had non-random block production, but fortunat= ely in Bitcoin we use proof-of-work. The confluence of too many things (powerful attacker, exact hashpower split= , perfect metastability) is necessary for this state --- and your solution = to this state --- to actually ***matter*** in practice. I estimate that it is far more likely my meat avatar will be destroyed in a= hit-and-run accident tomorrow than such a state actually occurring, and I = do not bother worrying about my meat avatar being destroyed by a hit-and-ru= n accident tomorrow. And in Bitcoin, leaving things alone is generally more important, because c= hange is always a risk, as it may introduce *other*, more dangerous attacks= that we have not thought of. I would suggest deferring to those in the security team, as they may have m= ore information than is available to you or me. >=C2=A0 This minor change of adding a fitness test to solve disagreements i= s intended to diminish the influence of delayed message passing, and yes th= ere are multiple solutions to this problem, absolutely, but bringing this f= act up just derails the important parts of the conversation.=C2=A0 > > By the client having limited visibility, then non-voting nodes who simply= pass messages *are* given a say in the election process, and that is a pro= blem.=C2=A0 =C2=A0Any attacker can more easily control=C2=A0when a message = arrives than a good fitness value.=C2=A0 =C2=A0The old 2013 solution was ab= out naming one side a looser, but that doesn't really help.=C2=A0 It isn't = just about calling one solution a winner and a loser. We need to make sure = that all descendants=C2=A0of weak solutions are also going to be weak - and= that my friend is the basis for a genetic algorithm. > > -Michael Brooks=C2=A0 > (my real name) Do you think emphasizing that this is your real name ***matters*** compared= to actual technical arguments? > > On Wed, Sep 30, 2020 at 6:45 PM ZmnSCPxj wrote: > > > Good morning Mike, > > > > > You are incorrect.=C2=A0 > > > > You make no argument to back this claim, so I will now refuse to engage= with you. > > > > Regards, > > ZmnSCPxj > > > > > > > > On Wed, Sep 30, 2020, 6:36 PM ZmnSCPxj wrot= e: > > > > > > > Good morning Mike, > > > > > > > > > ZmnSCPxj, > > > > > > > > > > The growing tare in growing disagreement continues to divide mini= ng capacity while the network waits for formation of future blocks - you'll= never get to complete=C2=A0consensus=C2=A0unless three is a way to avoid a= mbiguity in=C2=A0disagreement,=C2=A0which you have not addressed.=C2=A0 The= topic of my discussion is an exploitable condition, your three block plan = does not add up. > > > > > > > > > > I wrote the exploit before I wrote the paper. It is telling that = still no one here has refenced the threat model, which is the largest secti= on of the entire 8 page paper.=C2=A0 The security came before the introduct= ion of FPNC because security=C2=A0fundamentals=C2=A0is what drives the nece= ssity for the solution. > > > > > > > > > > The text you are reading right now was delivered using the mailin= g list manager=C2=A0Majordomo2, which I shelled in 2011 and got a severity = metric and an alert in the DHS newsletter. Correct me if I am wrong, but I = bet that just of my exploits has probably=C2=A0popped more shells than ever= yone on this thread combined.=C2=A0=C2=A0 Cryptography?=C2=A0 Sure, I'll br= ag about the time I hacked Square Inc. This is actually my current favorite= crypto exploit=C2=A0=E2=80=94 it was the time I used DKIM signature-mallea= bility to conduct a replay-attack that allowed an adversary to replay anoth= er user's transactions an unlimited number of times. After receiving=C2= =A0a normal payment from another Square user you could empty their account.= =C2=A0 This was reported ethically and it was a mutual joy to work with suc= h a great team.=C2=A0 Now it is not just impact, but I am also getting the = feeling that I have collected more CVEs, all this is to say that I'm not ne= w to difficult vendors. > > > > > > > > Argument screens off authority, thus, even if I have no CVEs under = this pseudonym, argument must still be weighted more highly than any author= ity you may claim. > > > > > > > > > To be blunt; some of you on this thread are behaving like a virgi= n=C2=A0reading a trashy love novel and failing to see the point =E2=80= =94 Just because you aren't excited, doesn't mean that it isn't hot. > > > > > > > > > > The exploit described in this paper was delivered to the Bitcoin-= core security team on August 4 at 9:36 PM PST.=C2=A0 The industry standard = of 90 days gives you until November 2nd. Now clearly, we need more time. Ho= wever,=C2=A0if the consensus is a rejection, then there shouldn't be any co= ncerns with a sensible 90-day disclosure policy.=C2=A0 > > > > > > > > I am not a member of this security team, and they may have better i= nformation and arguments than I do, in which case, I would defer to them if= they are willing to openly discuss it and I find their arguments compellin= g. > > > > > > > > The attack you describe is: > > > > > > > > * Not fixable by floating-point Nakamoto consensus, as such a power= ful adversary can just as easily prevent propagation of a higher-score bloc= k. > > > > * Broken by even a single, manually-created connection between both= sides of the chain-split. > > > > > > > > Regards, > > > > ZmnSCPxj Regards, ZmnSCPxj