Re: [bitcoin-dev] Bitcoin XT 0.11A

From: Andrew LeCody <andrewlecody@gmail•com>
To: Cameron Garnham <da2ce7@gmail•com>,
	bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
Date: Sun, 16 Aug 2015 23:22:45 +0000	[thread overview]
Message-ID: <CAEX2NSfaPv0g07hfT31voGWX05Z6uaBsZOjhMkOwBr4mdHbPQw@mail.gmail.com> (raw)
In-Reply-To: <55D1167B.1060107@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4555 bytes --]

Cam, your scenario makes no sense.

> 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.

This would obliterate any confidence in Bitcoin Core. I seriously doubt
anyone would actually be ok with a pull request implementing this.

> 3. Setup good Atomic Swap markets.

Who would bother writing this code, let alone trading on these 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).

I doubt this is even possible.

On Sun, Aug 16, 2015 at 6:02 PM Cameron Garnham via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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 as
> > well.
> >
> > ---
> > Currently 0 mined blocks have voted for XT.
> >
> > If it ever gets close to even 50%, many things can happen that would
> > reshape the game completely.
> >
> > For instance:
> >
> > - Core could start boycotting XT by not relying to them and/or not
> relying
> > from them.
> >
> > - 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.
> >
> > 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.
> >
> > 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.
> >
> > It's a risky game to play.
> > ---
> >
> > 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". There
> > was a fair play alternative which is voting through coinbase scriptSig
> like
> > plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
> > 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 the
> > case.
> >
> > -----
> > 為せば成る
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6943 bytes --]