public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: odinn <odinn.cyberguerrilla@riseup.net>
To: "Jorge Timón" <jtimon@jtimon.cc>,
	"Danny Thorpe" <danny.thorpe@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Date: Wed, 19 Aug 2015 03:14:45 -0700	[thread overview]
Message-ID: <55D45715.4010107@riseup.net> (raw)
In-Reply-To: <CABm2gDp69g8H4Was2qzixPq3qwQ_smzzeFpE+y2GYEK6F4kUrw@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Firstly, XT is controversial, not uncontroversial;
Second, this issue has been beat to death quite a while ago
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987
Third, it poses major risks as a non-peer reviewed alt with a number
of problematic features (with the privacy problems recently mentioned
on this list being just one of them)
Fourth, it has not followed any semblance of process in terms of the
development funnel or BIPS process, with XT developers instead
choosing instead a dangerous path of hard forking bitcoin while being
well aware of miner voting on viable solutions which have followed
process.

The following proposals
http://bipsxdevs.azurewebsites.net/
regardless of what you think of any one of them, are deserving of
attention (BIP 100 / BIP 101) and are being voted on as you read this
by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
/fallback option.)  BIP 100 is probably the best of these (note, in
part, it schedules a hardfork on testnet in September).

Contentious hard forks are bad for Bitcoin.
https://bitcoin.org/en/posts/hard-fork-policy
You may want to read this again if you haven't recently.

There is no basis for further promoting XT by suggesting that it
should even be tested.

#GAVEL

On 08/19/2015 02:29 AM, Jorge Timón via bitcoin-dev wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 
>> Ya, so?  All that means is that the experiment might reach the
>> hard fork tipping point faster than mainnet would. Verifying that
>> the network can handle such transitions, and how larger blocks
>> affect the network, is the point of testing.
>> 
>> And when I refer to testnet, I mean the public global testnet
>> blockchain, not in-house isolated networks like
>> testnet-in-a-box.
> 
> I would expect any uncontroversial hardfork to be deployed in
> testnet3 before it is deployed in bitcoin's main chain.
> 
> In any case, you can already do these tests using 
> https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the
> new testchains are regtest-like (ie cheap proof of work) you don't
> need to test them "in-a-box": you can run them from many different
> places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have
> been perfectly made using #6382, it just didn't existed at the
> time. _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJV1FcVAAoJEGxwq/inSG8CAd8H/R9khvHJJaNKrq7tjzksyc6V
jNN8ApaYUOE/i+goKd7XaeW0LM0aUC5vdqOCud632zb9XGo6awlk0fML4FV+wsE0
e5EfVDKZJxQ7zbaNCXXKTUfC+XRpJlhJgfF9jDgTsKv2l8fALbz+U6tn65Ke8F4+
9A4jJCe8yjttjBkX+8wLsSeDkDsPxo7f29rPfI6YMtN4MYbdxGiLjrTuRWrVje8q
l+3IFxrqGwKQl3LygRQHmLosvcW8UZzGYIM7hCleE9NUpc9TdpyTXPB3+9O9h4ty
5vY9jZ6t2Ww9CeljzD8S+1Nycz7sHqeoBCie+WexY7aT/QV2WQxFp4qnpO7PMSs=
=UNYA
-----END PGP SIGNATURE-----


  reply	other threads:[~2015-08-19 10:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18  9:54 [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork? jl2012
2015-08-18 11:57 ` Micha Bailey
2015-08-18 18:52 ` Eric Lombrozo
2015-08-18 20:48 ` Danny Thorpe
2015-08-18 20:51   ` Eric Lombrozo
2015-08-18 21:06     ` Danny Thorpe
2015-08-18 21:17       ` Eric Lombrozo
2015-08-18 21:39         ` Danny Thorpe
2015-08-19  9:29       ` Jorge Timón
2015-08-19 10:14         ` odinn [this message]
2015-08-19 11:06           ` Jorge Timón
2015-08-19 11:25             ` odinn
2015-08-19 15:22               ` jl2012
2015-08-19 15:48                 ` Tier Nolan
2015-08-19 15:25               ` Jorge Timón
2015-08-19 17:30         ` Danny Thorpe
2015-08-19 18:33           ` Jorge Timón
2015-08-18 22:51 ` Ahmed Zsales
2015-08-19  2:53   ` Eric Lombrozo
2015-08-19  9:24 ` Jorge Timón
2015-08-19 10:34   ` jl2012
2015-08-19 10:53     ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D45715.4010107@riseup.net \
    --to=odinn.cyberguerrilla@riseup.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=danny.thorpe@gmail.com \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox