diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-04-04 12:07:28 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-04-04 12:07:38 +0000 |
| commit | ae09931f1a3876fd70ff79fb4b2c529c378e8d19 (patch) | |
| tree | 9246df28c7bee2afbfcd740f656ef8675582d24f | |
| parent | 9d42d586cad56c035e5c47499e38dd6fcec66bac (diff) | |
| download | pi-bitcoindev-ae09931f1a3876fd70ff79fb4b2c529c378e8d19.tar.gz pi-bitcoindev-ae09931f1a3876fd70ff79fb4b2c529c378e8d19.zip | |
Re: [bitcoin-dev] Statechain implementations
| -rw-r--r-- | 01/296c4d936706d3b9ff3db0fc94800f5b9d0b54 | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/01/296c4d936706d3b9ff3db0fc94800f5b9d0b54 b/01/296c4d936706d3b9ff3db0fc94800f5b9d0b54 new file mode 100644 index 000000000..556aceb97 --- /dev/null +++ b/01/296c4d936706d3b9ff3db0fc94800f5b9d0b54 @@ -0,0 +1,245 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 09702C07FF + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 4 Apr 2020 12:07:38 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by whitealder.osuosl.org (Postfix) with ESMTP id EE92587C74 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 4 Apr 2020 12:07:37 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from whitealder.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ppyM5UkcbcJK + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 4 Apr 2020 12:07:35 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch + [185.70.40.132]) + by whitealder.osuosl.org (Postfix) with ESMTPS id 67E1387C5C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 4 Apr 2020 12:07:35 +0000 (UTC) +Date: Sat, 04 Apr 2020 12:07:28 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1586002052; + bh=7d8ym44ss9L0fpOPRMFeAbX1AsDs054B/ZX6iy/Xd/8=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; + b=Uy89TeyTBLU2Ou5w80lODmk7IIJuKi+rq6H9KgIGOUCrZ4AdRxy3+hq7u7f7HrGc4 + Q/X6l4ujMRp3b8v0H+YLvaWPGxZk25SzQipaYIv3zO2sebQ+a6tiz5hxQt4VIHiOFA + F+J+P4UYi4MNEJgTk7PvbR1POhG+Tn+UywPFcgUQ= +To: Nadav Kohen <nadav@suredbits.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <fTTGFnQW00u5V8SFA29RIMEsAPMS6MojiCdFDCXVHGCE5GRp31ilw5xXeuMoZVREDCWvm-N_KFvPvPZ1qfgnCE6hUT8O1Lh6FZIYzrmuOGM=@protonmail.com> +In-Reply-To: <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com> +References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com> + <20200331103508.asvxujkhtifj6n7i@ganymede> + <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com> + <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com> + <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +Cc: Tom Trevethan <tom@commerceblock.com> +Subject: Re: [bitcoin-dev] Statechain implementations +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +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: Sat, 04 Apr 2020 12:07:38 -0000 + +Good morning Nadav, + +Indeed. + +It seems to me that practical deployments of statechains requires the state= +chain operator to be a trusted federation, possibly a k-of-n. +This is slightly better than a federated sidechain because the money can al= +ways be reclaimed on the blockchain layer very quickly in case of a loss of= + trust in the federation. +If the k-of-n is arranged in such a way that the signers can be identified = +(such as by use of old `OP_CHECKMULTISIG` or some combination of the propos= +ed `OP_CHECKSIGADD`) then it has the same "auditability", i.e. you can iden= +tify the pseudonyms of the members who cheated (which is not worth much, as= + getting a new pseudonym is trivial). + +It is helpful to remember that a k-of-n federation can only be trusted if y= +ou have full trust in at least (n - k + 1) members of the federation. + +Regards, +ZmnSCPxj + +> Hey all, +> +> So my main concern with the proposal as written is that the Statechain En= +tity (SE) can untraceably=C2=A0scam its users with the following attack: +> 1) Buy the utxo (have it transferred to a key it knows), this first step = +can be skipped if the utxo was created by the SE. +> 2) Transfer the UTXO to someone else, let it be for however long +> 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n a= +nd it=C2=A0 knows the full private key, x, from when it owned the UTXO (and= + had both shards), and so it can compute x/s_n =3D the current users shard.= + It can then sign for the current user, and forge a state transition to a k= +ey it owns before spending the UTXO on chain. +> +> The main problem here is that the user who had their funds stolen cannot = +prove to anyone that this has happened since the attack compromises their k= +ey. +> That said, I think this problem is easily fixed by adding a new user key = +to the protocol with which they must sign in order for the transfer to be c= +onsidered valid on the state chain. This way, if the SE wishes to steal the= + funds (which they still can), at least it is traceable/provable that this = +SE is not trustworthy as there is no evidence of a valid transfer for the f= +unds that have been stolen. +> +> Best, +> Nadav +> +> On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <bitcoin-dev= +@lists.linuxfoundation.org> wrote: +> +> > Thanks for all of the input and comments - I do now think that the decr= +ementing nSequence relative locktime backup system with kick-off transactio= +n is the way to go, including a fee penalty via CPFP to disincentivise= +=C2=A0DoS, as suggested.=C2=A0 +> > I have started a more detailed document specifying the proposed protoco= +l in more detail:=C2=A0https://github.com/commerceblock/mercury/blob/master= +/statechains.md=C2=A0which includes improvements to the transfer=C2=A0mecha= +nism (and an explanation of how this can be used to transfer/novate positio= +ns in DLCs). Always happy to get more feedback or PRs.=C2=A0 +> > +> > Tom +> > +> > On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com> = +wrote: +> > +> > > Hi David, +> > > +> > > Just for clarity, I left nChain over 2 years ago (having worked there= + since 2016). While there, I (along with other researchers) were given free= + rein to work on any ideas we wanted to. I had been interested in the scali= +ng of Bitcoin off-chain, and this was one of several things I spent time on= + (including things like sidechains,=C2=A0pegs and threshold signatures). Th= +is patent application came out of an idea I had to transfer ownership of UT= +XOs off-chain that has some similarities to the statechains proposal, which= + has shown there is interest and demand for this type of system.=C2=A0 +> > > +> > > Although I think the existence of this application is something to be= + mindful of, there are several important things to note: +> > > +> > > 1. Although there are similarities, the current ideas are significant= +ly different to those in the application.=C2=A0 +> > > 2. The key transfer protocol as described in the application is not s= +ecure (for several reasons, including as discussed above, by Albert and Bob= + etc.) - and a different mechanism is required.=C2=A0 +> > > 3. Decrementing timelocks (as suggested in the application) are prior= + art (Decker-Wattenhofer 2015), and in any case any implementation will mos= +t likely use an 'invalidation tree' relative locktime backup mechanism for = +open-ended UTXOs.=C2=A0 +> > > 4. The patent application has not been granted (it was made in May 20= +17) and the international search report rejected it on the grounds of prior= + art.=C2=A0 +> > > +> > > Tom +> > > +> > > On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org> wro= +te: +> > > +> > > > On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via bitcoin= +-dev wrote: +> > > > > Hi all, +> > > > > +> > > > > We are starting to work on an implementation of the statechains c= +oncept ( +> > > > > https://medium.com/@RubenSomsen/statechains-non-custodial-off-cha= +in-bitcoin-transfer-1ae4845a4a39), +> > > > > +> > > > > [...] +> > > > > There are two main modifications we are looking at: +> > > > > [...] +> > > > > +> > > > > 2. Replacing the 2-of-2 multisig output (paying to statechain ent= +ity SE key +> > > > > and transitory key) with a single P2(W)PKH output where the publi= +c key +> > > > > shared between the SE and the current owner. The SE and the curre= +nt owner +> > > > > can then sign with a 2-of-2 ECDSA MPC. +> > > > +> > > > Dr. Trevethan, +> > > > +> > > > Would you be able to explain how your proposal to use statechains w= +ith +> > > > 2P-ECDSA relates to your patent assigned to nChain Holdings for "Se= +cure +> > > > off-chain blockchain transactions"?[1]=C2=A0 +> > > > +> > > > =C2=A0 =C2=A0 [1] https://patents.google.com/patent/US20200074464A1 +> > > > +> > > > Here are some excerpts from the application that caught my attentio= +n in +> > > > the context of statechains in general and your proposal to this lis= +t in +> > > > particular: +> > > > +> > > > > an exchange platform that is trusted to implement and operate the +> > > > > transaction protocol, without requiring an on-chain transaction. = +The +> > > > > off-chain transactions enable one computer system to generate mul= +tiple +> > > > > transactions that are recordable to a blockchain in different +> > > > > circumstances +> > > > > +> > > > > [...] +> > > > > +> > > > > at least some of the off-chain transactions are valid for recordi= +ng on +> > > > > the blockchain even in the event of a catastrophic failure of the +> > > > > exchange (e.g., exchange going permanently off-line or loosing ke= +y +> > > > > shares). +> > > > > +> > > > > [...] +> > > > > +> > > > > there may be provided a computer readable storage medium includin= +g a +> > > > > two-party elliptic curve digital signature algorithm (two-party E= +CDSA) +> > > > > script comprising computer executable instructions which, when +> > > > > executed, configure a processor to perform functions of a two-par= +ty +> > > > > elliptic curve digital signature algorithm described herein. +> > > > > +> > > > > [...] +> > > > > +> > > > > In this instance the malicious actor would then also have to coll= +ude +> > > > > with a previous owner of the funds to recreate the full key. Beca= +use +> > > > > an attack requires either the simultaneous theft of both exchange= + and +> > > > > depositor keys or collusion with previous legitimate owners of fu= +nds, +> > > > > the opportunities for a malicious attacker to compromise the exch= +ange +> > > > > platform are limited. +> > > > +> > > > Thank you, +> > > > +> > > > -Dave +> > +> > _______________________________________________ +> > bitcoin-dev mailing list +> > bitcoin-dev@lists.linuxfoundation.org +> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + + |