diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-06-13 01:22:38 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-13 01:22:44 +0000 |
| commit | 46016edf744497b6c710a894ddb88fafab82eb3f (patch) | |
| tree | 3e4aa5be7c1939489fe59edac8b0e12200a63fb1 | |
| parent | e46e08822e655c3106d7110f427f8ea8e5597deb (diff) | |
| download | pi-bitcoindev-46016edf744497b6c710a894ddb88fafab82eb3f.tar.gz pi-bitcoindev-46016edf744497b6c710a894ddb88fafab82eb3f.zip | |
Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
| -rw-r--r-- | e0/bea46e1e218906823d4e1f2e04c7c1e69f1fb4 | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/e0/bea46e1e218906823d4e1f2e04c7c1e69f1fb4 b/e0/bea46e1e218906823d4e1f2e04c7c1e69f1fb4 new file mode 100644 index 000000000..61ad314dc --- /dev/null +++ b/e0/bea46e1e218906823d4e1f2e04c7c1e69f1fb4 @@ -0,0 +1,139 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CF7A220F + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Jun 2019 01:22:44 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch + [185.70.40.136]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3A1B2174 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Jun 2019 01:22:42 +0000 (UTC) +Date: Thu, 13 Jun 2019 01:22:38 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1560388960; + bh=jQl87smcBMC5aqa4O2ANXrpzJE4+9nJo0TLAsIjvbxo=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=DT1uHpVV3em7pZADsXefegQYSqx/YV8hUOv30vZ0HsJUudYjHIzcgCATtkdoHJHnL + Jfe4jTiU516yzCZaQXLZ1ka1HmY8fTx7b94b3b3WBgy/bynwON+u1vztED9wBFCJ+B + x7ZfGFjq+1Pq9Gq3YzeO7y0fFwuqOByFuS3scgcs= +To: Ruben Somsen <rsomsen@gmail.com> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <xc6X8fAM-1Aow8xjcyCFL7Z5r0s7Vmr_FFo1Mjoz5Hh12I0_6VAU-mlX9nj0aNZjJZ3qq5ehICalNeOqgEh1ziaZiF-Zvz7s42HGK-LXoM0=@protonmail.com> +In-Reply-To: <CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com> +References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com> + <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> + <CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com> + <L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com> + <CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + 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: Thu, 13 Jun 2019 13:26:27 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic + blind signing server +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 Jun 2019 01:22:44 -0000 + +Good morning Ruben, +> > an early draft +> +> I meant an early draft of Statechains, sorry if that was confusing. +> But yes, it's essentially no different from channel factories without +> eltoo. + +Sorry, I am referring to current issues with channel factories, which were = +not addressed in the original channel factories paper. +Basically, the "Stale Factory" and "Broken Factory" problems. +Broken factory seems unsolvable. +Stale factory is fixable if the channels within the factory use `SIGHASH_NO= +INPUT` (assuming it gets into Bitcoin) for all unilateral paths (use `SIGHA= +SH_ALL` for cooperative paths). + +> +> > If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it see= +ms this transitory/common key can be used for the chaperone. +> +> That is a good point. One thing I have not yet fully analysed are the +> privacy considerations. Perhaps we don't want to reveal X on-chain. + +On reflection, probably best not to. +It requires a script that reveals the pubkeys. +And it now becomes possible for the server to monitor the blockchain for re= +velation of server pubkey in a spend path. +This will let the server know, after-the-fact, that it was signing blockcha= +in transactions. +This might not let it preemptively censor or otherwise disrupt, but it *cou= +ld* sell the private fact that a statechain was used. +Combining it via MuSig is probably best, as the server is now unable to rec= +ognize even the pubkey (assuming it never is informed `X`). + +> +> > This would be nearer to my own Smart Contracts Unchained +> +> Adding scripting is not my preferred approach. The beauty of the +> system is that the server doesn't evaluate any scripts whatsoever. + +On reflection, this is probably best. +As the server is blinded, it cannot determine anything about the message be= +ing signed. + +On the other cognition sub-agent, however, a simple scripting that allows "= +if somebody provides x of H(x) plus signature A, sign a blinded message M1,= + else if after 2:30PM PST on Jun 24 2019 if somebody provides signature of = +B, sign a blinded message M2" could still potentially be useful, and might = +allow "programmable escrow" like I imagine Smart Contracts Unchained could = +allow. + +> +> That being said, Smart Contracts Unchained (SCU) can be inserted quite +> elegantly as a separate smart contracting layer. +> +> The observation is that anything that can be done with a UTXO +> on-chain, can also be done off-chain via Statechains, including SCU. + +The Real (TM) observation is that anything that can be done with a UTXO onc= +hain, can also be done offchain via any updateable offchain cryptocurrency = +system, whether Statechains, Spillman, Decker-Wattenhofer, Poon-Dryja, or D= +ecker-Russell-Osuntokun. +(I should probably look up the authors of the Statechains paper to make my = +naming convention consistent) + +One might observe that any updateable offchain cryptocurrency system worth = +its salt would have some way of unilaterally dropping transactions onchain. +Those transactions would create new UTXOs that can be spent by further tran= +sactions. +By presenting those "further transactions" to the offchain system, we can p= +rovide an argument that the offchain system can just "append" those "furthe= +r transactions" to the existing unilateral-case transactions, then cut-thro= +ugh the further transactions on its next update (i.e. delete the current UT= +XOs spent and insert the new UTXOs introduced by the "further transactions"= +). +(In the case of Statechains, you would present this argument to the signers= + of the latest `userPubKey`, not to the server, who is unaware of the seman= +tics of what it is signing) + + +Regards, +ZmnSCPxj + |