diff options
author | Peter Todd <pete@petertodd.org> | 2014-12-16 07:36:42 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-12-16 12:36:56 +0000 |
commit | 8964626009cd228003701aa7e678b6740cb870fc (patch) | |
tree | a9011e1b163333d4563422041dabbe195f0df350 /e5 | |
parent | 3ca79502c3291c656ebc86c62a2f01fd44c9aa97 (diff) | |
download | pi-bitcoindev-8964626009cd228003701aa7e678b6740cb870fc.tar.gz pi-bitcoindev-8964626009cd228003701aa7e678b6740cb870fc.zip |
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Diffstat (limited to 'e5')
-rw-r--r-- | e5/68c95e92e23857dec9148c420a95aea463c3db | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/e5/68c95e92e23857dec9148c420a95aea463c3db b/e5/68c95e92e23857dec9148c420a95aea463c3db new file mode 100644 index 000000000..3cfef4ff2 --- /dev/null +++ b/e5/68c95e92e23857dec9148c420a95aea463c3db @@ -0,0 +1,146 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1Y0rN2-0007Yq-3b + for bitcoin-development@lists.sourceforge.net; + Tue, 16 Dec 2014 12:36:56 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.149.101 as permitted sender) + client-ip=62.13.149.101; envelope-from=pete@petertodd.org; + helo=outmail149101.authsmtp.com; +Received: from outmail149101.authsmtp.com ([62.13.149.101]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1Y0rN0-0004Jy-8v for bitcoin-development@lists.sourceforge.net; + Tue, 16 Dec 2014 12:36:56 +0000 +Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) + by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBGCalOj014093; + Tue, 16 Dec 2014 12:36:47 GMT +Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com + [75.119.251.161]) (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBGCagYl087110 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Tue, 16 Dec 2014 12:36:45 GMT +Date: Tue, 16 Dec 2014 07:36:42 -0500 +From: Peter Todd <pete@petertodd.org> +To: Alex Mizrahi <alex.mizrahi@gmail.com> +Message-ID: <20141216123642.GA19943@savin.petertodd.org> +References: <54876653.4020403@certimix.com> <548769FA.5040406@bluematt.me> + <CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com> + <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> + <54880492.9060300@intersango.com> + <CAE28kUQ1tzCXp=90-1ZQG67f2Vh3uCrApJTbx+Lf1r-1byV4Lw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" +Content-Disposition: inline +In-Reply-To: <CAE28kUQ1tzCXp=90-1ZQG67f2Vh3uCrApJTbx+Lf1r-1byV4Lw@mail.gmail.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Server-Quench: 32452cd9-8520-11e4-9f74-002590a135d3 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdwQUHFAXAgsB AmIbWlZeU1t7XWY7 bA9PbARUfEhLXhtr + VklWR1pVCwQmQm52 dU9JO0VyfwJHeX4+ ZENhVnQVX0Z+cEQu + FkdJHWgEZXphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL + NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOzMm SB0OVTAuG0wDSG06 + ZwcnJlNUF0YYM0N6 Llo9WRoAKRgVBEVZ ESMFCjJDIREGQWIz + BBlXW1JWGz1UQCE0 +X-Authentic-SMTP: 61633532353630.1024:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 75.119.251.161/587 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Score: -1.5 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record +X-Headers-End: 1Y0rN0-0004Jy-8v +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of + burn on parent chain +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 16 Dec 2014 12:36:56 -0000 + + +--0OAP2g/MAC+5xKAE +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote: +> Usually at this point people say "we assume that miners aren't going to +> collude, otherwise even Bitcoin is not secure". +> Well, this is BS. The fact that a pool can acquire more than 50% of total +> hashpower was successfully demonstrated by ghash.io. +> But the thing is, Bitcoin doesn't offer one a good way to attack the whol= +e, +> as there are powerful factors which will work against the attacker. +> But this is not the case with sidechains (or any merged-mined chains, for +> that matter). +> And once you have a clear incentive, collusion is much more likely. + ++1 + +It's notable that blockstream hasn't published much if anything concrete +on what exactly you'd use merge-mined sidechains for; they're even worse +than Ethereum in that regard. + +> > Proof of Burn is a real cost for following the rules. +> > +>=20 +> So what? As long as cost is less than revenue, it is OK. + +It's even better than that: if an attack does happen, the participants +in the consensus system have an incentive to defend against it to +maintain the value of their tokens. Proof-of-burn allows that defense to +be in response to a threat, and essentially unlimited in size. + +So now any attacker knows that if they launch an attack in theory the +response could be as strong as the value of the system itself. + +This can be improved upon with systems that allow the tokens to be +burned, "internal" proof-of-burn. This suffers from "nothing-at-stake" +vulnerabilities to an extent, OTOH within the context of the system it +is a true sacrifice of value; probably not a big deal in a zookeyv-style +block-DAG where multiple lines of history can be combined. Here the +incentives of the defenders are even more strongly tipped towards +burning their value to preserve the system, not unlike +replace-by-fee-scorched-earth thinking. + +--=20 +'peter'[:-1]@petertodd.org +00000000000000000e0c078667795abe21bfdebb913eba60cc7a625c732f0a89 + +--0OAP2g/MAC+5xKAE +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQGrBAEBCACVBQJUkCdWXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw +MDAwMDAwMDAwMDAwMDAxMjRjOTFiMGIxYTE1ZWU2Njc0OTlmNzkzMTNhODQ5YzIx +MmIyMWYyYzMwYjQ1NDgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 +ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsOcAgAjaNgy0PyWqR2yeXXqjuD5i+U +syiGdJ3fw473PgTQRijBtmOPsBGy5/Z1/338GzxVcf0u6Yr9s5002pD09xcNfVJa +kTYCDLEwulOHYnmsdUyN51SM+dQohCgzhtPISfyJiMTuzn/N+MSP/7AseSiquegh +Y/I0vLaJboKmZZ+10xZyF0EfQQ5Ks3HpJwru5gwGxPL0NODGyTw/V9blpb06UqVt +c0mHLJe9X0947N3CyOBX3ftXBfXIKeew3KOcLOsdGmCrinUEiQejiF024VwZtDys +RXVP9qrZ+wJtYF/QJAOAgNQijNlynCHCqAjrO4Je0X5TXYRbzqjWAJvZQz5qZA== +=Ka3f +-----END PGP SIGNATURE----- + +--0OAP2g/MAC+5xKAE-- + + |