diff options
| author | Oleg Andreev <oleganza@gmail.com> | 2017-04-12 17:43:50 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-13 00:43:53 +0000 |
| commit | c85144dc4d35a1325deb5224c75e735ad96cb8c6 (patch) | |
| tree | 52887bf3c0600b9c07a05f735ac432659d9a0b33 | |
| parent | d06a98284c3b9010685edb004db5a02ff65c556a (diff) | |
| download | pi-bitcoindev-c85144dc4d35a1325deb5224c75e735ad96cb8c6.tar.gz pi-bitcoindev-c85144dc4d35a1325deb5224c75e735ad96cb8c6.zip | |
[bitcoin-dev] Deploying CT in Bitcoin without extension blocks?
| -rw-r--r-- | 69/0ae9cd07ad3735000a35087084925aec1f758e | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/69/0ae9cd07ad3735000a35087084925aec1f758e b/69/0ae9cd07ad3735000a35087084925aec1f758e new file mode 100644 index 000000000..a2a25ce8f --- /dev/null +++ b/69/0ae9cd07ad3735000a35087084925aec1f758e @@ -0,0 +1,176 @@ +Return-Path: <oleganza@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id C46354A3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Apr 2017 00:43:53 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com + [209.85.192.176]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38E7E159 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Apr 2017 00:43:53 +0000 (UTC) +Received: by mail-pf0-f176.google.com with SMTP id s16so21020058pfs.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Apr 2017 17:43:53 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=from:content-transfer-encoding:mime-version:subject:message-id:date + :to; bh=+NV6MI8tWdJ6QRRVhDvwZhUw/js4QKsVQ+6AooCYNSE=; + b=o9OGdiBVFNaC2Q38hm2bxFHkvy1xCoeN0djUfindH2WEXPQRrM4BXikpfIJD6xf3Bq + od0ItlbnAHUe+7Ncd81it3LUF7Rl4y3FU8VefIPOTF6Opiv0IPwZDAnBlOD1RLGS4ZX4 + nwlychC1f07mYbCH6x1X1CXDuA90gRwLsfPFeg/fPNQXsYjKQZScWcYDNNt2ABXNuILF + 0oIMCHrTug+EDEc/e0+PkahKH6hfIBBxKPnJkGjDElfFL2eirzjdHnWCWxj1gHthX7EA + G1ydPoSVuBxIe9+ZkYlUH+Z/ljO7GwlskQMu5ph7ZcjtMOEaEB4OBeAh7d/NlWxrDfyP + zRTQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:from:content-transfer-encoding:mime-version + :subject:message-id:date:to; + bh=+NV6MI8tWdJ6QRRVhDvwZhUw/js4QKsVQ+6AooCYNSE=; + b=jU27dNZOWgKvpZZrD7ya102MySnAk+/J7WVqigv68a3IyYt+iARNTzcNQDmKDzoBLC + pQ1c10Jur3uXoIi6+xHsMwCcGoqTZr5EOlFA1KQlK/nvEOz8BtEYoRl1OYUPOwf1TGXs + xjxxICvo2MLPUKrMtiSwwGlnHwPlXOO5dAKmF2Lb9m0fhulhCJdle8PrwM4DNZ9qugUi + ethny0Tk0cbtcOI+4K7Y8zuHQ6I6p08od931yzUO1N88d0DYHy2uTS07xX7to8hx6/NP + eHHMDxpwxXGkAo1ML9m0rr2KdsX9cy2HQkZO6eMyru8al8qoSi+6ICPfDfmKKnknD11J + oSxQ== +X-Gm-Message-State: AN3rC/4z16UT92bvcQ6l8oNqCT27EhSl8ZKWBIcmTLpAjBveZ7Pw4xOX + Dt4Xm889LWDH3XUPY0w= +X-Received: by 10.98.59.9 with SMTP id i9mr521584pfa.50.1492044232416; + Wed, 12 Apr 2017 17:43:52 -0700 (PDT) +Received: from [192.168.1.126] ([52.119.113.96]) + by smtp.gmail.com with ESMTPSA id + 11sm38571702pgf.28.2017.04.12.17.43.51 + for <bitcoin-dev@lists.linuxfoundation.org> + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 12 Apr 2017 17:43:51 -0700 (PDT) +From: Oleg Andreev <oleganza@gmail.com> +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: quoted-printable +Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) +Message-Id: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com> +Date: Wed, 12 Apr 2017 17:43:50 -0700 +To: "bitcoin-dev@lists.linuxfoundation.org" + <bitcoin-dev@lists.linuxfoundation.org> +X-Mailer: Apple Mail (2.3273) +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE 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] Deploying CT in Bitcoin without extension blocks? +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol 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: Thu, 13 Apr 2017 00:43:53 -0000 + +(This is a sketch, not a fully-formed proposal, just to kick off the = +discussion.) + +Confidential Transactions (by GMaxwell & Poelstra) require a new = +accounting model,=20 +new representation of numbers (EC points as Pedersen commitments) and = +range proofs=20 +per number. Setting aside performance and bandwidth concerns (3-4Kb per = +output,=20 +50x more signature checks), how would we deploy that feature on Bitcoin = +network=20 +in the most compatible manner? + +I'll try to present a sketch of the proposal. I apologize if this = +discussion already +happened somewhere, although I couldn't find anything on this subject, = +apart from Elements=20 +sidechain proposal, of course. + +At first glance we could create a new extblock and transaction format, = +add a protocol to +"convert" money into and from such extblock, and commit to that extblock = +from the=20 +outer block's coinbase transaction. Unfortunately, this opens gates to a = +flood of +debates such as what should be the block size limit in such block, = +should we=20 +take opportunity to fix over 9000 of pet-peeve issues with existing = +transactions +and blocks, should we adjust inflation schedule, insert additional PoW, = +what would +Satoshi say etc. Federated sidechain suffers from the same issues, plus = +adds=20 +concerns regarding governance, although it would be more decoupled, = +which is useful. + +I tried to look at a possibility to make the change as compatible as = +possible, +sticking confidential values right into the existing transaction = +structure and +see how that would look like. As a nice bonus, confidential transactions = +would have=20 +to fit into the hard-coded 1 Mb limit, preserving the drama around it = +:-P + +We start with a segwit-enabled script versioning and introduce 2 new = +script versions: +version A has an actual program concatenated with the commitment, while = +version B=20 +has only the commitment and allows mimblewimble usage (no signatures, = +non-interactive=20 +cut-through etc). Legacy cleartext amount can nicely act as "min value" = +to minimize +the range proof size, and range proofs themselves are provided = +separately in the +segregated witness payload. + +Then, we soft fork additional rules: + +1. In non-coinbase tx, sum of commitments on inputs must balance with = +sum of commitments + on the outputs plus the cleartext mining fee in the witness. +2. Range proof can be confidential, based on borromean ring signature. +3. Range proof can be non-confidential, consisting of an amount and raw = +blinding factor. +4. Tx witness can have an excess value (cf. MW) and cleartext amount for = +a miner's fee. +5. In coinbase tx, total plaintext reward + commitments must balance = +with subsidy,=20 + legacy fees and new fees in the witness. +6. Extra fees in the witness must be signed with the excess value's key. + +The confidential transactions use the same UTXO set, can be co-authored = +with plaintext inputs/outputs +using legacy software and maybe even improve scalability by compressing = +on-chain transactions +using mimblewimble cut-through. + +The rules above could have been made more complicated with export/import = +logic to allow users +converting their coins to and from confidential ones, but that would = +require +more complex support from miners to respect and merge outputs = +representing "plaintext value bank", +mutate export transactions, which in turn requires introduction of a = +non-malleable TxID +that excludes miner-adjustable export/import outputs. + +The rules above have a nice side effect that miners, being the minters = +of confidential coins,=20 +can sell them at a premium, which creates an incentive for them to = +actually support +that feature and work on improving performance of rangeproof validation = +(e.g. in GPUs). + +Would love to hear comments and criticism of that approach. + +Thanks! +Oleg. + + + + |