From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EBE5411C2 for ; Thu, 18 Feb 2016 16:14:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DCAC170 for ; Thu, 18 Feb 2016 16:14:20 +0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id g203so78699306iof.2 for ; Thu, 18 Feb 2016 08:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=biXnCbBKB864dXoHpwOkUKwgL40K3695yfacNGCfjDg=; b=xIEeudlzLgEFgmw4omeFYXzfPDHtKl0SzsLSrQTiMSCoyMLJ+z7njjXU27kD9ZWrv5 c1IrcKhpyc4KXA8P4CAUOfUVZsTJEDvPZ9ATWJv6rNZqd0LI9S99qRq/9TwRYJ1pUJDB An4P+dtYLGNtBCEKMgAMIg5m/J3VPDI5UnPo/jZvfQW4gcYv1ulECMjqIcNuEvt1rWUb hLxJh1MXHMVIwtJ1ZMrYwDY1lIB+43/9J/q6QGcIRqJZa60eqOBsrxP1MDLolgfTBQHd FywzttREiYJRbBuAWHznFDA6bin/j1EZLUlKSung0/phgJqYb3AZj5kkfTq2Hu2/qmOi gpow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=biXnCbBKB864dXoHpwOkUKwgL40K3695yfacNGCfjDg=; b=JiVsZFk+VMqNazDV56t4qKeaOW+oA+FTpTFetTCY7J26fYOXErbELc95w7rAtofJJZ wl5eisDjWuQaMz71ppPL8jbcV6J4F9qN5X6pvxMES3IXLRLZAO8sEW6iQkH2B/rB9v4l h7Xm0de6AdgJCxfQ427qaoZ3PxxtOFfDQ0NYhMsQX5fK4RCsnx0c3brj8NhjKBD54Ijh x/TV1c8lxnK6IyrLryMSb7OQTBxsuH7fsHGjIooTkxYA11qw4ffTW6N8mqBuNN9uJALg aZ8ElW8GfYj0QWTwd0i/zutdMpLVK/FbhXjrV8mDd4TM8ScUXW325t3sIeOmDBOUIZ3I opqg== X-Gm-Message-State: AG10YOS0WJfreKrAld32zwjZxKgG8zN7SnJIZQlpGp38u2ks1hIHwqbidnBPh2Vrr1t9qEuKIP+mHb/nQlJ04A== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr9261787ioe.135.1455812059536; Thu, 18 Feb 2016 08:14:19 -0800 (PST) Received: by 10.79.77.65 with HTTP; Thu, 18 Feb 2016 08:14:19 -0800 (PST) Date: Thu, 18 Feb 2016 16:14:19 +0000 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11402a9eab2a2e052c0da8b3 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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 Subject: [bitcoin-dev] Sig-Witness and legacy outputs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:14:22 -0000 --001a11402a9eab2a2e052c0da8b3 Content-Type: text/plain; charset=UTF-8 I wrote a bip last year about extended transaction information. The idea was to include the scriptPubKey that was being spent along with transactions. https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki This makes it easier possible to verify the transactions locally. An extended transaction would contain the current transaction and also the CTxOuts that are being spent. For each entry in the UTXO set, a node could store UTXO_hash = hash(txid_parent | n | CTxOut) Witness transactions will do something similar. I wonder if it would be possible to include the CTxOut for each input that isn't a segregated witness output, as part of the witness data. Even for witness data, it would be good to commit to the value of the output as part of the witness. There was a suggestion at one of the conferences to have the witness data include info about the block height/index of the output that each input is spending. The effect of this change is that nodes would only have to store the UTXO_hashes for each UTXO value in the database. This would make it much more efficient. It would also make it easier to create a simple consensus library. You give the library the transaction and the witness and it returns the UTXO_hashes that are spent, the UTXO_hashes that are created, the fee, sigops and anything that needs to be summed. Validating a block would mostly (famous last words) mean validating the transactions in the block and then adding up the totals. The advantage of including the info with the transactions is that it saves each node having to include a lookup table to find the data. --001a11402a9eab2a2e052c0da8b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wrote a bip last year abou= t extended transaction information.=C2=A0 The idea was to include the scrip= tPubKey that was being spent along with transactions.