Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9B42C71 for ; Sat, 30 Jul 2016 23:18:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 23ADEE9 for ; Sat, 30 Jul 2016 23:18:43 +0000 (UTC) Received: by mail-qt0-f182.google.com with SMTP id u25so86558762qtb.1 for ; Sat, 30 Jul 2016 16:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Uqi7paiJLo9fTDVtk6JXDyVRYwIUlXRZoi5Cn6CEXQc=; b=Y8ANRVB2GsAiMz0vKuPrAT9tOiEl3fHeWmCbgXXyrFduJtCpyzgb9bQwX4RmMHXBYM 6oRLF2lqbp35ucbT5wiMspcmCTXL+NXGzZGieRqf9awf9aURlVI73xciLJDpAtt1Wbag 23RC1XHjnNtT9CKVFtuCtO+8GpoVIdqxDeh+QEkgTP1CJT2DgxpebZEBoaUo5r+qPhYn zASPdoEV3hoQf680Kpk/hGUgw19jsaL6M6wlpIL8jq7uEB+aqZDBFq08f7o9o9P8dbdU VjVSynWUXMaCTb1hPMbJZshckOc3GXaBMnOYOVZ3/AA242DI+9arNdyAiD9uivQjfahO 6ufQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Uqi7paiJLo9fTDVtk6JXDyVRYwIUlXRZoi5Cn6CEXQc=; b=Mnym2IGfVEGiQBE4eW2XnrPW1doXRTLG2dH2QvSFWNnx9jY4UaDL9GSmu6uYzKfvm9 Xdr19U/uLPokGnIAmBQq830jjc46Cbyz0xMU1BGWSDaJrJ5yqAotB3VhdZJRoUf2Uitu OCmKCbVH1uRsZ42ByPX+zeQA8xxAvgr41zUhyw6qChpLmkARUfRbAJ8xNpoq0/P3OxPk 91vHoyo9CPiUrvdwyEV1hmUH2bqGClwidCcoVxAu2Y9Vpnmggj1Dux8UCZnFhh5HJFsJ vO3DNDohvtXQ0U5VsrChLzxs84gNT2B9Xg5L+3BHkOQCC+Q/DPT9S17r2w4x7Yg1YsJc BZ7w== X-Gm-Message-State: AEkooutyJmIsQX1FVvEEDfaHhaETy0Tl55sZa+yl1mAw/3q1F0r07gG8F418D3uAZ8g4OA== X-Received: by 10.200.45.108 with SMTP id o41mr76995964qta.100.1469920721960; Sat, 30 Jul 2016 16:18:41 -0700 (PDT) Received: from [192.168.1.100] (ool-4575fa8d.dyn.optonline.net. [69.117.250.141]) by smtp.googlemail.com with ESMTPSA id s66sm5759599qkh.20.2016.07.30.16.18.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jul 2016 16:18:41 -0700 (PDT) From: Paul Sztorc To: Bitcoin Dev Message-ID: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@gmail.com> Date: Sat, 30 Jul 2016 19:18:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Sun, 31 Jul 2016 01:27:11 +0000 Subject: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 23:18:43 -0000 Dear list, As we know, it would be desirable for Alice, running an SPV client, to ti= p (say $5) anyone who can prove to her that a given block has invalid con= tent. If no one takes these tips, then this is weak evidence that the entire bl= ock is valid. Alice gets validation, full nodes can get paid...this idea = goes back to Satoshi's whitepaper. In my view, "alerts" are relatively straightforward: a new OP CODE (detai= ls below) st. the txn only succeeds if it references invalid block conten= t on a "pretender block". However, my background reading seems to reveal that "fraud proofs" (as th= ey are now called) require some kind of tremendous engineering overhaul. = Can anyone point me to these large problem(s)? Regards, Paul Sztorc ------------------------------------ Fraud Proof, Simple (?) 1. "OP FraudProof", which: 1. Contains arguments [a] block number (from Alice), [b] block header, a= nd [c] merkle path from header to an invalid transaction*. 2. Checks to see if the provided header _is_ in the position which Alice= requested. 2. Checks to see if the header _is_ valid (ie, has sufficient work). 3. Checks to see if the merkle path _does_ lead from the header to "some= thing invalid"*. 2. This OP Code can then be used in a transaction of the form: Inputs: 1 from Alice 0.2 from X** Output: 1.2 to Alice, timelocked (or) 1.2 to X, OP FraudProof . 3. Alice could sign this txn and circulate it, waiting for "X" to add the= second signature.=20 "Eric", for example, might sign. As soon as Alice get's Eric's signature,= she [1] assumes the block *is* invalid, and [2] stops offering to buy Fr= audProofs on it. If Eric does not deliver the fraud proof, Alice gets her money back + 0.2= BTC from Eric (for wasting her time). Alice can't lose -- she either buy= s a fraud proof for 1, or she gets a free 0.2. Eric can't lose either. Either he doesn't sign (and nothing happens), or = he places himself in a position to trade a FraudProof for 1 BTC. - FraudProof can use "OP Equal" to request fraud for a certain block. - This can all happen through the lightning network. * "invalid transaction" is defined either [1] as a script which fails, or= [2] a double-spend (headers/paths to 2 txns spending the same input). Th= is definition does not catch bad coinbase transactions, but this doesn't = concern me. Those outputs aren't spendable for 100 blocks, and anyway, SP= V clients could be programmed to never accept them (it would be annoying,= but possible). ** For simplicity, I assume that "FraudProof sellers" will pre-identify t= hemselves (and their unspent outputs, etc, by making them "watching only"= or whatever). --- Now, I wouldn't describe this as a "weekend project", but I wouldn't desc= ribe it as an "engineering overhaul" either. Just a new OP Code, and code= to create / scan for these "Alert Transactions". So, if the idea is 5+ y= ears old, what's the hold up? I've also heard that segwit will help, but don't understand why.