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 E43BE955 for ; Thu, 13 Apr 2017 01:43:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CECB7175 for ; Thu, 13 Apr 2017 01:43:47 +0000 (UTC) Received: by mail-qk0-f178.google.com with SMTP id d131so37799266qkc.3 for ; Wed, 12 Apr 2017 18:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=; b=EHKVs2gQPX6pAzikxDsXg+NnTlrOwOeJmT1w4fWLwruoGFg9e9EnnxqoFX6a0bfy/o FdU5cOCWkVORUQ2Xa5OcJ2FUAV9bsSvd8UxXTyNIa9yN6m7o48PWDi2vyJQd0mmHTojz /I6KGHmW7xUG1o+LZqnvYTGVqswU01PueLkTphewQAcy15BKD7ZitetJxm0ivapXtUYD kyoOiIXRYARMY0Vp6T/TbWPbEh43kdN9FX/zauvPfA5rNelK8h2Xn5u4EJ0C8Wg1fgaP VmRRDMM7LN6231sTpGJpPyJX+e1Xht8gwO9D02qmOmOJMvceHdY3HJHsNw5SgOCwSFfB Iv0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=; b=HJTZBdi12atkv3+VJSGzo13Ha5cTpuwi6feeEJxT4GgNg2wmHsXsakURUvQHXhnyU8 Qt7/9br4zzRqt5H23g4cG9SBiuj3WztKsX75zrKeH4NsMCgvZRlCQJOUZyPXvl5bQmsO r5OPrzWsS67F2w8CvglAp/jaXnRZhwiyHJL/FaJmC84WIrBWi8/Sn6gYNbrfnEndstTX xRhzsTtCw+rPinjCzQeA7dc1X1txzuktx3t2JdOROzX7Mi2I/0BK5CKVMTzDvPwKTCMF UPuQ08pIUKlYQi01n3xiC87wZEy2J6A1Xq06IB0fPg3Ysfd0SmX+WOIJxbvIiFh2Z8Vs d+PA== X-Gm-Message-State: AN3rC/4ChFuh03SJIlCNBlrj1logMvy8Y/EXVxrW8XZR8zdT7LjF3zN3 GUCMyaBFE+8c8xU81VR65IcrqCnw6A== X-Received: by 10.55.73.6 with SMTP id w6mr483663qka.153.1492047826988; Wed, 12 Apr 2017 18:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT) Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT) Reply-To: adam@cypherspace.org In-Reply-To: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com> References: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com> From: Adam Back Date: Wed, 12 Apr 2017 18:43:46 -0700 Message-ID: To: Oleg Andreev Content-Type: multipart/alternative; boundary=001a114a922cb7322f054d027494 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:43:49 -0000 --001a114a922cb7322f054d027494 Content-Type: text/plain; charset=UTF-8 See this soft-fork proposal from Felix Weiss https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html Adam On Apr 12, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > (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, > new representation of numbers (EC points as Pedersen commitments) and > range proofs > per number. Setting aside performance and bandwidth concerns (3-4Kb per > output, > 50x more signature checks), how would we deploy that feature on Bitcoin > network > 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 > 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 > 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 > 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 > 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 > 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 > has only the commitment and allows mimblewimble usage (no signatures, > non-interactive > 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, > 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, > 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. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114a922cb7322f054d027494 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See this soft-fork proposal from Felix Weiss=C2=A0


On Apr 1= 2, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
--001a114a922cb7322f054d027494--