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 D7582279 for ; Sun, 16 Aug 2015 23:02:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27471102 for ; Sun, 16 Aug 2015 23:02:32 +0000 (UTC) Received: by pdrg1 with SMTP id g1so48936519pdr.2 for ; Sun, 16 Aug 2015 16:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=DFe5VNK0ZtRUnFRXW5wsJfP9P1eDm4KngiCSsAAc08I=; b=KNN259qo6ZFlJiQvyXn0ix78lB5s+io1QzEU7KnpMQetM7lKLjUuMJjp/ZZNLnZMHX XeMdWRKM1rzg/NzCpKo3cBa7noLmj8rsjE9rykM5Xsj8y4ftVKmj4i8snPUeeJH2TWOc 9NLC68ofNXbcn+HD9IqyQfNe36OTN+xFHNc4YJhDH4Yxsd8Atthcn3i10lErdMjSHTQj Q5LqIuvR3wqPpkJF5KCPgUmsshuxpr1L+THGIkwCp8sKcVdigJGLU+dQTub9Z3th164e PvKo/hIgbHIq/rH+/FqoCHIPQvm56ZPrNP7znz3gf0rCiOWSqBkfymVb2R9/mE4tS6pg AQ7A== X-Received: by 10.70.109.165 with SMTP id ht5mr40901013pdb.137.1439766151877; Sun, 16 Aug 2015 16:02:31 -0700 (PDT) Received: from [192.168.1.126] ([168.70.69.242]) by smtp.googlemail.com with ESMTPSA id hi1sm12376249pbc.47.2015.08.16.16.02.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Aug 2015 16:02:30 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Cameron Garnham Message-ID: <55D1167B.1060107@gmail.com> Date: Mon, 17 Aug 2015 07:02:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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 Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 23:02:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that it is important to note that Bitcoin XT faces a natural uphill battle. Since it is possible to setup atomic inter-fork coin trades. I do not see how Bitcoin XT could possibly win if Satoshi decides to sell 10000 XTBTC for BTC everyday for the first 100 days after the fork. In many ways Satoshi gets to decide the winning fork just by his huge economic investment in Bitcoin. Here is some simple game-theory for non-consensus forks: 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version string. 2. Encourage all miners to false vote for the Bitcoin XT fork. - Now people have no-idea what % of the economy Bitcoin XT holds. - Making it impossible for people to put economic faith behind Bitcoin XT. 3. Setup good Atomic Swap markets. 4. Setup a fork of Bitcoin XT that allows people to easily make a transaction only on the XT fork (while leaving the original BTC coins untouched). This means that the Bitcoin XT fork will be born per-mature. Probably with only a small % of hashing power behind it (contrary to the almost 100% that falsely claim to support it). It will be embarrassing that for the goal of larger blocks, XT instead has blocks (before re-adjustment) every 2h. The price for XTBTC coins will plummet, Satoshi progressively dumping his 1M stash over a year or so will make sure that it doesn't recover either. I cannot see how Bitcoin XT is but-not in a extremely weak position from game theory. I'm sure smarter people than I could come up with even more ways to disrupt non-consensus forks. Cam. On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote: > I posted this to /r/BitcoinMarkets but I thought I might post it here a= s > well. >=20 > --- > Currently 0 mined blocks have voted for XT. >=20 > If it ever gets close to even 50%, many things can happen that would > reshape the game completely. >=20 > For instance: >=20 > - Core could start boycotting XT by not relying to them and/or not rely= ing > from them. >=20 > - Core could appropriate the version string of XT, making it impossible= to > know how much they are progressing and a losing bet to actually execute= the > fork. >=20 > This kind of node war if the factions were sizeable would make it very > risky to transact at all - balances in new addresses could end up > vanishing. Usability of the system would plummet. >=20 > Note that any disagreement between the network and the biggest economic= > actors - mainly the exchanges at this point, "wallet services" maybe - > would mean BTC plummets. Hard. And so would confidence. >=20 > It's a risky game to play. > --- >=20 > PS: I consider this attempt at takeover about as foul as it gets. The > equivalent of repeating a referendum until a yes is obtained: the > reasonable reaction to this is actively blocking said "referendum". The= re > was a fair play alternative which is voting through coinbase scriptSig = like > plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment= =2E > Once a majority is obtained in this way, devs have to react or if they > don't then this sort of foul play would be justified. But this wasn't t= he > case. >=20 > ----- > =E7=82=BA=E3=81=9B=E3=81=B0=E6=88=90=E3=82=8B >=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 --IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXRFoUACgkQBJ8cMDO159b73gD/c4PzfzqrMlm5X5w+Bq2LR1Yc 8cPbgFyWxLjLUIzJIZ0A/ilCMIrQ0NTclLx/rR7X+QgMSSaTlJovL47YHdaXy1VQ =UTBc -----END PGP SIGNATURE----- --IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF--