Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 765572575 for ; Fri, 5 Apr 2019 17:46:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C99547E9 for ; Fri, 5 Apr 2019 17:46:38 +0000 (UTC) Received: by mail-wr1-f46.google.com with SMTP id y7so8944808wrn.11 for ; Fri, 05 Apr 2019 10:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/NtUnXjtWQjCRZDIxRVNufaCgyY71ynymnGCWC9Jy8c=; b=kfEctknncN7Ftht07i+tAH4hZLaKZrpDvEo0AaSpw3y3LeT9ldhG4UEq2+/uY1aMC0 XkAgtYNa7E9/8+D3N7d5IwtXPr70FRn1KJ/AK9NI5myDH31bylq+x7u6GV4shU6oCbdQ 4sY9KtDdUUPKJvlhlTaEkNMQX+rmKR8/wKxjc1ym80LliDnU2SWasA5TI5zWnvQObWNc WCflAXCuNjsnz1fHHxKno430OJxdQ5XOygb4J3z/cxLb+ZWYFWs3iGbvSGDu+C5YUSUV MH/MlAy389pcGou5BppIPGS7SZOo2654UBQ4vcib3SIC+ybEdtqpS2S4Cpv3CwFjcsDL 74tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/NtUnXjtWQjCRZDIxRVNufaCgyY71ynymnGCWC9Jy8c=; b=Gf1OjZ+hOPi00J7wqblk25bsjUrTD7tc2d+vdIPCfb5QcCXkCnnS0kgTDyRzOyaS/i oXSoF8DxrsX5SeLXFlcaUqDvpgYGlfjeFHX6d+y23G5jbOuATK7eh2wNtFmtHHEARyZs 6Xp8SId/JPLjLvxszNUyrcQNaxxVhRADGPf1sq7Np/VTz1hvfUwEAMSJJB4eMQ9h8ED6 CaBFg1H+AEwFijZLaCT5t5+tPsBSnLTk/VljEfNbkV+ol3yif1/DK/fkPxGAlxc1/M9w KoZTiOxTBIqleo537h96b2sXIuo/YZh8K34saPXzNLv79PiykX8NHBm5qmWu3SKwOPhv CmZw== X-Gm-Message-State: APjAAAWoGw91UCux5jclvUdB17MeBEoypxBZ484dB3LiGX/0ydOtn6N7 07TZ/GODSquSQB857uWHIgNJyXR1 X-Google-Smtp-Source: APXvYqyLbwMHrnLvOncc7IJrQUYih9TU6cLqgK9SobGbmg6+ji5IkRDlusIuBdBCRW6mpKO5sqi+OQ== X-Received: by 2002:a5d:5343:: with SMTP id t3mr8955511wrv.49.1554486397301; Fri, 05 Apr 2019 10:46:37 -0700 (PDT) Received: from [192.168.43.146] ([80.12.63.231]) by smtp.googlemail.com with ESMTPSA id b9sm5251173wmc.9.2019.04.05.10.46.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 10:46:36 -0700 (PDT) To: ZmnSCPxj References: From: Aymeric Vitte Message-ID: <392367fe-b1d7-7d47-01de-ebb4b7142ead@gmail.com> Date: Fri, 5 Apr 2019 19:46:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 X-Mailman-Approved-At: Sun, 07 Apr 2019 10:36:01 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Smart Contracts Unchained 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: Fri, 05 Apr 2019 17:46:39 -0000 Hi, Apparently you are not a fan of ethereum, as far as I can tell ethereum sidechains look like a mess with stupid tokens/transactions flooding the network while they are completely centralized, but some bitcoin sidechains can easily compete with this too, like Tether, don't even understand how anyone can give some credit to that stuff the way it is implemented, and if bitcoin fails that would be the same as for ethereum Most likely everyone would agree if the escrow disappears, but not sure at all, let's imagine 1 to N put 10K on the table for a game, they update the states and at the end N wins everything, N is rich and don't care finally if the others cheaters have their coins locked (and to lose 10K), same with setting up a new escrow to resolve the conflict I think that you should highlight this (and what private key corresponds to E + h(E | s) * G, not sure it's trivial for everybody), probably a way to get this more decentralized is to reward the escrows (what is the interest here for people to run a smart contract platform?) For lightning, maybe it's a question of wording, I consider it as a sidechain AND methods that can be used by other sidechains, as well as the others you quoted, even if only two people in the world use lightning, it is still decentralized, because it sustains itself alone Regards Aymeric Le 05/04/2019 à 01:52, ZmnSCPxj a écrit : > Good morning Aymeric, > > >> What if the smart contract platform(s) disappear? >> > It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds. > You do this by all participants simply signing with their participant keys and taking the first branch of the script. > This branch does not require the participation of the smart contract platform, at all. > If all participants can agree to the result of the smart contract without dispute, then they can exit the platform even after the platform disappears. > > Now of course there will be participants who will not cooperate in such a case, for example if they were doing some betting game and "lost". > But at least it gives the possibility of doing so, and it will not be as massive a loss. > > Indeed, if the smart contract platform code is open source, it may be possible to set up another implementation of the smart contract platform. > And it would be possible to at least try to convince all participants to switch to that new platform (again, via the "as long as everybody agrees" escape hatch). > Again, this is not possible with current federated sidechains, or Ethereum (if Ethereum fails, all ETH becomes valueless). > >> The proposal induces a very centralized system, to my knowledge all of >> existing sidechains whether on bitcoin or ethereum are centralized, >> except lightning (if we forget that someone must watch what others are >> doing when you are on a trek in Nepal) > I would not lump together Lightning with sidechains. > Indeed, this design moves things closer to true offchain techniques (as in Lightning) than to sidechain techniques. > > So while centralized, it is less centralized than a federated sidechains. > >> Now I don't get why a sidechain should be a blockchain on top on another >> one (given also that we can't consider bitcoin or ethereum as >> decentralized today, so the path might be long for the sidechains...), >> the latest is used to store the final state, the former does not have to >> store forever the intermediate states, then it could just use a >> decentralized system (not necessarilly blockchain-like) to store the >> intermediate states and maybe be a distributed escrow >> >> I know, easy to say, please do it (why not), now the fact that >> sidechains claim to be decentralized or that they will be is just >> misleading people (that's not the case of your proposal but it does not >> say what happens if the platforms go down) > Perhaps it can be a next step. > > Regards, > ZmnSCPxj