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 C5B2071 for ; Sun, 26 Jun 2016 12:12:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.161.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51C51155 for ; Sun, 26 Jun 2016 12:12:14 +0000 (UTC) Received: by mail-yw0-f172.google.com with SMTP id i12so132239192ywa.1 for ; Sun, 26 Jun 2016 05:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=cX3PDbubv6Z+lQA5rZCjo7PieuFiqMURv1xh3ztB2qc=; b=TlCAazA2zPfe+JOsr4HtiYcTTWd15CcUGRtHm2nQMmgzWO7YrXlFBaILianoDW7ATz bnSh0HMVcUEoKjKmN3AhxIESS+nwcl8jIgaxTj92AfKkl35zuzp2HpPpkrMrDxOIut42 tb/NykDAkWe9qZzXqM2Q1eXMwV2jrU5T/lomxvayaYrufzXymUMo8i7jO6HtD6iMSu79 cKlWMjnj0ovY7IKgnQDEnB/LxNOP/YqgzdV44CJOr0aTX/X+Elsc0HwBa14snAzlEarP YiBht7pLFCIRqy0dW2glKOYqN1OL2JlU67qNq4WaGQJEAm7P6DmmdXthaV5lmk+xPVyf Kxqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=cX3PDbubv6Z+lQA5rZCjo7PieuFiqMURv1xh3ztB2qc=; b=ZPzCLhgfmayCnm3ymFI7lFNYFVDLDSZ/u66U4KnfUpDAi60wrGSXOaecJOve+7auK3 GedLpNnTIC5Iq7GfBkKH7bFzxU96PABmF+0fFq+8zlVaMSzLC0R1RP6E+lM8jiZECQaR u299jqidGdlnDZut9ftuUrphoG6YeTGbpUnT70C5Q+QKDVz6N7w6f/Rkzx2tArmnfEOZ 7E/1VZ1P37oJkgFuYb4umEAkqHbIihb3gfOdRFRv9yQE3txXMJpjzEl0J4JL6c1606EA fZ9xfbkSROryWBbY+1ZPfFUIqbVqDFMdgdG5HjiWrcr5y7gwjO0eOmSNSJe5jB9RUJ24 sndw== X-Gm-Message-State: ALyK8tKgskbu2Gy2kK1kDMB5JPvshvbtajyVXgG8VoTzChDlYw2qA3FEkSl4AkFw2dy26NY7Gyi3rJsYC+TVvQ== X-Received: by 10.37.65.144 with SMTP id o138mr7965004yba.87.1466943132047; Sun, 26 Jun 2016 05:12:12 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.72.68 with HTTP; Sun, 26 Jun 2016 05:12:11 -0700 (PDT) From: Erik Aronesty Date: Sun, 26 Jun 2016 08:12:11 -0400 X-Google-Sender-Auth: 5ALsIpMnOsQu93dM10w9VIoEEEo Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11c05a544aa03f05362d500b X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, 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] parallel token idea & question 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: Sun, 26 Jun 2016 12:12:14 -0000 --001a11c05a544aa03f05362d500b Content-Type: text/plain; charset=UTF-8 token miners who will work to the a new token signal readiness to secure that token by posting a public key to the bitcoin blockchain along with a collateral and possibly a block mined from a side chain, or some other signal proving sufficient participation (allows for non-blockchain tokens). coin moved to the new token set is sent to a multisig wallet consisting of miners who have signaled readiness, with nlocktime set to some time in the future coin sits in that wallet - the new token doesn't even have to be a chain, it could be a DAG, or some other mechanism - following whatever rules it pleases any time, miner of the new system can move coin back to the main chain... trivially and following whatever rules are need. also, any time a miner fails to follow the rules of the new system, they lose their collateral any sufficient consortium of miners/participants in the side chain can, of course, steal that coin...but that is true for all sidechains - and to some extent bitcoin - anyway does this seem too simplistic or weak in some way? --001a11c05a544aa03f05362d500b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
token miners who will work to the a new token signal readi= ness to secure that token by posting a public key to the bitcoin blockchain= along with a collateral and possibly a block mined from a side chain, or s= ome other signal proving sufficient participation (allows for non-blockchai= n tokens).

coin moved to the new token set is sent to a = multisig wallet consisting of miners who have signaled readiness, with nloc= ktime set to some time in the future

coin sits in = that wallet - the new token doesn't even have to be a chain, it could b= e a DAG, or some other mechanism - following whatever rules it pleases

any time, miner of the new system can move coin back t= o the main chain... trivially and following whatever rules are need. =C2=A0= also, any time a miner fails to follow the rules of the new system, they lo= se their collateral

any sufficient consortium= of miners/participants in the side chain can, of course, steal that coin..= .but that is true for all sidechains - and to some extent bitcoin - anyway<= /div>

does this seem too simplistic or weak in som= e way?=C2=A0
--001a11c05a544aa03f05362d500b--